Return to BSD News archive
Xref: sserve comp.arch:27963 comp.unix.bsd:7580 comp.os.linux:15056 comp.arch.storage:672
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux,comp.arch.storage
Subject: Re: IDE faster than Mips SCSI disk
Message-ID: <36775@cbmvax.commodore.com>
Date: 6 Nov 92 21:06:02 GMT
References: <1992Nov6.033942.21194@ntuix.ntu.ac.sg>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Followup-To: comp.arch.storage
Organization: Commodore, West Chester, PA
Lines: 82
eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>These figures are not meant to be a thorough study. More of a provocation
>for more soul searching. The widespread belief that SCSI-2 is "defininely
>faster than IDE" is questionable, in fact under some circumstances, entirely
>false.
Yes, with MAJOR qualifications (below).
> The results are not surprising for those who study the technical
>specs of these disks. IDE has more potential for high speed because of its
>lack of protocaol overhead. Its closeness to the disk also make it very
>reliable and efficient.
This is an advantage for very small reads. For larger reads, the
protocol overhead is minimal compared to transfer time. Also, protocol
overhead can vary by orders of magnitude depending on the SCSI chip used,
the driver, and the hardware around it.
> There are advanced disks which can do simultaneour multiple-head reads,
>but these techniques can also be used for IDE as well.
No they cannot (or at least not as well), since IDE doesn't support
the equivalent to the SCSI disconnect. With SCSI, you can burst at 10MB/s to
drives that can only sustain 1-4MB/s, and keep several of them busy at a time
on a single bus.
> IDE is just a simple interface definition, just like SCSI-2, but IDE,
>is optimised for HARD DISKS, SCSI is not. SCSI is more general purpose.
SCSI is more general purpose, but a good scsi implementation should
only add a small number of microseconds to each IO. A slow or old or poor
implementation could easily add 1-5 milliseconds to each IO (a lot if you're
doing 512 bytes/IO).
>The mips machine under test runs on ultrix. Although it has up to 10Gbyte
>of hard-disk, it is not so heavily loaded. We only use it for email and
>news feed. Fragmentation can be severe because I cannot even have 32
>megabyte free space in /usr/tmp , only 30 Mbytes.
Well, this certainly can affect your tests A LOT.
> IOZONE writes a 30 Megabyte sequential file consisting of
> 61440 records which are each 512 bytes in length.
> It then reads the file. It prints the bytes-per-second
> rate at which the computer can read and write files.
512 byte reads aren't exactly large. Most Unix FS's use larger blocks
than that, and most stdio packages use large BUFSIZ's than that, I think. The
difference in IO speed between 512 byte IO's and 32K IO's (at the SCSI level)
can easily be 1:20. Actually, your kernel/fs is probably doing 1-8K transfers
to the Unix buffercache, and filling from that. Also, Unix always uses a
buffercache and copies to user-space in the kernel, while some micro's (such as
the Amiga) will DMA direct to user space whenever possible.
> 345684 bytes/second for writing the file
> 641985 bytes/second for reading the file
These aren't real fast times. I have a 1gig disk on my Amiga which
does 4MB/s through the filesystem for large reads (the disk can only sustain
about 4.3MB/s off the platters). Times like this tell you nothing about the
interface unless you (a) have SCSI and IDE versions of the SAME MODEL drive,
and (b) are running them under the same OS. You still have to factor in
the hardware to implement both. For example, and 53c80 SCSI chip will be
slow regardless, since it's a glorified parallel port, while an 53c720 will
push the SCSI interface to it's limits.
When you use a benchmark, you MUST understand it's limitations to
interpret the results. IOZONE is a very crude benchmark, especially for
making cross-interface or worse yet cross-OS comparisons.
I advise you learn more about how things work before you go making
blanket statement like the ones above. Also, comp.arch.storage is more
appropriate than comp.arch.
Followups to comp.arch.storage.
--
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.