Return to BSD News archive
Xref: sserve comp.unix.bsd:7714 comp.benchmarks:2355 comp.arch:28068 comp.arch.storage:678
Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!caen!zeus.ieee.org!rutgers!bagate!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.unix.bsd,comp.benchmarks,comp.arch,comp.arch.storage
Subject: Re: Disk performance issues, was IDE vs SCSI-2 using iozone
Message-ID: <36994@cbmvax.commodore.com>
Date: 12 Nov 92 05:24:34 GMT
References: <1992Nov7.102940.12338@igor.tamri.com> <36794@cbmvax.commodore.com> <1992Nov10.170022.21624@igor.tamri.com>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 132
jbass@igor.tamri.com (John Bass) writes:
>From: jesup@cbmvax.commodore.com (Randell Jesup)
>> You're right about the early SCSI days - for example, scsi got zone
>>recording earlier, etc. The base technology in IDE/SCSI is now the same, so
>>it comes down to software and interface issues. I'll agree that for a single-
>>disk system and small transfers, IDE has a slight margin in speed over SCSI,
>>due to lower command overhead.
>Given small transfers qualification, "Slight margin in speed" is highly
>debatable .... The ability to do read scheduling and write placement
>based upon knowing geometry and current head/spindle position allows for
>30%-700% better semi-random small file I/O with the right filesystem design.
You're making the assumption that IDE doesn't hide that from you as
well. It does. Some (many?) current IDE drives use the cylinder/head/sector
registers as merely a convoluted way to specify a block number, use zone
recording, etc. I strongly suspect that this will continue, as the benefits
of zone recording, sector replacement, etc are too large to ignore (a number
of filesystems (most?) require that the device drivers present them with a
perfect media, no unusable blocks. This requires remapping of bad blocks in
the disk controller (SCSI or IDE) or in the device driver itself. Usually the
controller has a better chance to do a good job at this.)
>> Once per sector? Don't PC's use the ReadMultiple/WriteMultiple
>>commands? I guess not (which matches what I've heard elsewhere). Our IDE
>> I don't understand your comment about "poor man's disconnect". While
>>you may be waiting for an interrupt, unless you have multiple IDE busses you
>>can't use your second IDE drive until the IO on the first is complete.
>
>Yes, Yes ... the interrupt for WD1003/IDE interfaces means the 512 byte sector
>buffer is full, and must be emptied. R/W Multiple are used, but it requires
>handling a transfer request interrupt for each sector, or busy waiting on
>data_request in the command status register ... hence poor man's disconnect
>from the processor bus.
I think you're confused. The CAM-ATA spec (and all the IDE drives I've
played with) says that when read/write Multiple is used (with SetMultiple),
you get 1 interrupt per N sectors. From CAM-ATA rev 2.3:
9.12 Read Multiple Command
The Read Multiple command performs similarly to the Read Sectors command.
Interrupts are not generated on every sector, but on the transfer of a block
which contains the number of sectors defined by a Set Multiple command.
> For WD100? cards, there is a single buffer per
>controller ... on the IDE model there is a buffer per drive ... and each
>can be active from what I can tell selected by the drive select bit(s).
Nope. The entire command must complete before you select the other
drive. No disconnect, no multiple simultaneous IO's.
>> Write-buffering (starting to be commonly available as an option on
>>SCSI drives) can help in avoiding slipping revs.
>While some speed can be gained by this practice, all ability to handle
>error conditions responsibly is generally lost. I am not a big fan of
>lookaside bad block handling to a slow microprocessor ... it only
>SIGIFICANTLY reduces throughput when important data gets spared ... leading
>to difficult to understand IN-FIELD performance problems. Filesystems
>should know and deal with media problems ... even though most UNIX's
>either don't or have the drivers do the fix ups.
There's a big philosophical argument over who should deal with media
problems. The consensus seems to be that they should be pushed into the
lowest level possible (fs->driver->host controller->drive controller). Having
written both filesystems and device drivers, I must agree with that (and yes
I've had to implement bad-block mapping at the driver level, such as for IDE).
Yes, write-buffering does lose some error recovery chances, especially
if there's no higher-level knowledge of possible write-buffering so
filesystems can insert lock-points to retain consistency. However, it can be
a vast speed improvement. It all depends on your (the user's) needs. Some
can easily live with it, some can't, some need raid arrays and UPS's.
>>As a multi-disk interface, or generalized IO interface (tape drives, CDROM,etc)
>>SCSI has a large edge. Also, IDE can only handle 2 devices. Even if IDE
>>tape drives and CDROMs were available (they're not), you'd rapidly start
>>needing multiple IDE interfaces.
> Tapes are (or will be) here, and I
>expect CDROMS (now partly proprietary & SCSI) to be mostly IDE & SCSI
>in the future. IDE is already extending the WD1003 interface, I expect
>addtional drive support will follow at some point, although multiple
>hostadapters is a minor cost issue for many systems.
There are rumbles in that direction. I'm not certain it's worth
it, or that it can be compatible enough to gain any usage. Existing users
who need lots of devices have no reason to switch from SCSI to IDE, and
systems vendors have few reasons to spend money on lots of interfaces
for devices that don't exist. The reason IDE became popular is that it was
_cheap_, and no software had to be modified to use it.
>>>Even the fastest 486 PC UNIX systems are filesystem CPU bound to between
>>>500KB and 2.5MB/sec ... drive subsystems faster than this are largely
>>>useless (a waste of money)
>> This is a combination of poor interfaces and the OS interface.
>>AmigaDos tries to do transfers direct to user buffers where possible,
>What I said was enough ... the UNIX interfaces are more general by DESIGN
>and a simplistic OS can surely take additional short cuts beyond page
>flipping ... AND SOME UNIX's do, and in some cases more should. Other than
>pushing your product, I don't see the utility in knocking UNIX and pumping
>AmigaDos. But thanks for your posting anyway.
Sorry if I went too deep into it; most people don't realize the sorts
of IO speeds that are possible. I also wouldn't call AmigaDos simplistic
(I would call MSDOS that, if I called it an OS at all). AmigaDos is more
complex (though in different ways) than many of the older, "clean" unixes
like V7 (and larger, too). Certainly it is designed with different targets
in mind. Blanket statements like "drives faster than X are a waste of money"
are dangerous to make. Such things often depend on factors you're making all
sorts of assumptions about, starting with OS/FS and primary use of the drive.
For example, people doing lots of high-speed from-disk animation _really_
want high throughput for large transfers.
Other reasonably modern OS's can also get very good IO numbers, such
as QNX.
>As a side note, I saw a reference a while back to the IDE standard in
>progress ... How can I get a copy?
Check the SCSI BBS (719) 574-0424.
--
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup
Disclaimer: Nothing I say is anything other than my personal opinion.