From owner-freebsd-scsi Mon Oct 19 21:21:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03513 for freebsd-scsi-outgoing; Mon, 19 Oct 1998 21:21:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03507 for ; Mon, 19 Oct 1998 21:21:34 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id WAA01524; Mon, 19 Oct 1998 22:21:00 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810200421.WAA01524@panzer.plutotech.com> Subject: Re: Sequential Disk I/O In-Reply-To: <000201bdfbd5$c21984a0$0100a8c0@whistle.bitstream.net> from "Thomas F. Keefe" at "Oct 19, 98 10:00:13 pm" To: keefe@cse.psu.edu (Thomas F. Keefe) Date: Mon, 19 Oct 1998 22:21:00 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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