[lug] hard drive speeds

Jeffrey B. Siegal jbs at quiotix.com
Tue Sep 28 16:31:29 MDT 1999


Sean Reifschneider wrote:
> By "burst transfer" I presume you mean "In the drive cache, in which case it's
> probably also in the system cache so the drive isn't being hit anyway"?

No, I actually used the wrong term.  I didn't mean burst transfer rate.  I meant
media transfer rate.

But even burst transfer rate (cache to host) can be important.  As someone else
indicated, one way (and probably the most valuable way, aside from simple
buffering) that on-drive caches are useful is that they cache data that are
passing under the drive head while waiting for the requested sector to spin
over.  Often these cached data are soon requested by the host from the on-drive
cache, because they are subsequent sectors in a file.  

> PCs don't tend to have the capacity for taking a dozen PCI SCSI controllers...
> The PCI bus is only marginally faster than 80MB/sec anyway...

This is true.  And a single PCI bus probably can't handle much more than two or
three high end SCSI drives *if there are a lot of sequential transfers*.  If the
drives spend a lot of time seeking, then the more drives the better.

> Too bad RAM prices have doubled in the last month.  A month ago the price
> difference between SCSI and IDE would buy you half a GB of CAS2 RAM...

Yes, but if you can wait a little while they'll probably come back down before
too long.

> >The numbers to look at are spin rate, seek time, and burst transfer rates.  How
> >to interpret these numbers and make trade offs depends on the application.
> 
> I would argue that.  "burst transfer rate" tends to represent "out of the
> cache" speeds, and has nothing to do with data density.

Again, my mistake.  You can add media transfer rate to the list. Burst transfer
rate also has some value (so I would leave it on the list) but media transfer
rate is usually more important.

> Oh?  What about the IDE RAID systems with a ton of controllers and one drive
> per interface?  Many of them claim better-than-SCSI performance.

I'd have to see a specific apples-to-apples comparison. I tend to doubt that IDE
would prevail, for two reasons:

1. IDE lacks tagged-command-queuing.  Even with one drive per controller, it is
impossible for an IDE subsystem to optimize accesses as well as a SCSI
subsystem.

2. My overwhelming experience is that the highest performance disk assemblies
(which, when assembled into RAID, make for the highest performance arrays) tend
to be available only in SCSI.



More information about the LUG mailing list