Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Oct 1998 22:21:00 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        keefe@cse.psu.edu (Thomas F. Keefe)
Cc:        freebsd-scsi@FreeBSD.ORG
Subject:   Re: Sequential Disk I/O
Message-ID:  <199810200421.WAA01524@panzer.plutotech.com>
In-Reply-To: <000201bdfbd5$c21984a0$0100a8c0@whistle.bitstream.net> from "Thomas F. Keefe" at "Oct 19, 98 10:00:13 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Thomas F. Keefe wrote...
> I am trying to write the logging portion
> of a database and have had trouble getting
> good performance. I am trying to avoid seek
> and rotational latency by writing consecutive
> 512 byte blocks to the disk.

You'd get better performance by writing larget blocks, most likely.

> Here are some details. I am using
> Mach/Lites, with the drivers for the Adaptec 
> aic7xxx controller ported from FreeBSD 
> (the version from around 9/97).

Is this with the old or new SCSI layer?  The SCSI layer in FreeBSD was
replaced in mid-September with a new, CAM-based SCSI layer.

> I am using
> an Adaptec 2940UW with a Western Digital
> Enterprise 2G wide SCSI drive (I have tried
> some other drives as well.)

The controller is okay, but I've seen reports of very poor performance from
Western Digital drives when tagged queueing is enabled.  In fact, in the
new CAM SCSI layer, we've disabled tagged queueing for those drives because
one user reported getting 1.5MB/sec performance when tagged queueing was
enabled and 8MB/sec when it was disabled.

> The writing is done by two tasks (processes) 
> so that the next write should always be ready when 
> the previous one finishes. I am able to verify
> that multiple SCSI requests are in the adapter
> concurrently. I have also verified that the
> SCSI write requests are to consecutive logical blocks.
> 
> However, even with 8 requests in the controller,
> the average time to complete a request is about
> 4ms. This amounts to a few sectors written
> per revolution. I get similar results with iozone 
> under FreeBSD. When the block size is 512 bytes, 
> the throughput is about 50KB/sec. (for a raw device). 
> When the block size is large the bandwidth hits 
> several MB/sec.
> 
> Is it possible to achieve sequential I/O rates
> (i.e., no seek latency and no rotational latency)
> with small write requests? Any insight you can 
> provide will be appreciated. Thanks.

One thing to keep in mind is that you won't be able to achieve very good
performance at all with small block sizes unless you're able to get a large
number of tagged transactions to the drive at one time.

I don't know what your SCSI subsystem is based on (you only mentioned
porting the Adaptec driver, not which Adaptec driver or what your SCSI
subsystem is like), but if it is based on the old FreeBSD SCSI subsystem,
you'll only be able to have 4 transactions outstanding to the disk at once.

Another problem is that your disk supposedly has horrible tagged queueing
performance.  If you're trying to get good throughput with small
transactions, I'd suggest using a drive that behaves a little better.  Most
IBM and Seagate disks work pretty well.

For instance, I've got an IBM Ultrastar 9ZX (9G, 10000RPM).  Running iozone
with 512 byte blocks for a 256MB file, I get:

IOZONE performance measurements:
        8054322 bytes/second for writing the file
        14070326 bytes/second for reading the file

With 64K blocks, I get:

IOZONE performance measurements:
        14559211 bytes/second for writing the file
        15929410 bytes/second for reading the file

This is on a filesystem of course, not a raw device.  And this is with CAM,
not the old SCSI subsystem.  So it is possible to get better performance
with small block sizes.  You probably just need to get a better disk and
make sure you can handle more outstanding tagged transactions.

Ken
-- 
Kenneth Merry
ken@plutotech.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810200421.WAA01524>