*BSD News Article 7372


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!swrinde!news.dell.com!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: IDE vs SCSI-2 using iozone
Message-ID: <1992Nov3.185543.22418@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <1992Nov2.085559.18528@ntuix.ntu.ac.sg> <a9nd02fU293D01@JUTS.ccc.amdahl.com>
Date: Tue, 3 Nov 92 18:55:43 GMT
Lines: 52

In article <a9nd02fU293D01@JUTS.ccc.amdahl.com> gab10@heatwavecd.amdahl.com (Gary A Browning) writes:
>In article <1992Nov2.085559.18528@ntuix.ntu.ac.sg>,
>eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>>
>> [ Numbers showing SCSI-2 is approximately equal to IDE on reads and blows
>>   IDE's socks off on writes ]
>>
>
>From your numbers it looks like the SCSI disk has an on-disk cache; note that
>the results for reading the file are comparable but the results for writing
>have changed by a factor of 2.  When writing, the disk can tell the controller
>it is done before it actually writes the data onto the disk.  When reading,
>it has to be more honest; it has to complete the disk access before it can
>acknowledge (assuming the file is not still in the cache from the write
>operations).
>
>If you use a larger file size, you can minimize the effect of the cache since
>it will be unable to hold all of the data and will have top perform disk
>activity.

Well, besides the fact that he probably wants improved performanace as the
result of caching, rather than eliminating it's effect... (I know, I know,
the point was to get number unbiased by benchmark loading characterstics)

I think the SCSI stuff is faster due to it's ability to do multiple I/O's
for write simultaneously.  It's also possible (and Julian may be working on
it now) to do the multiple I/O trick for SCSI reads, with similar improvement
expected.  I don't think the SCSI disk has on-board cache.  If it's controller
cache you are worried about, don't.  With the exception of some antiquated IDE
controllers (of which I have several) IDE doesn't support controller cache
(unless disk hardware cache counts here -- entirely possible for IDE).

If a cached controller gets better performance, then I say buy one; that it's
possible to twist the access methods for the SCSI to slow it down to IDE
speeds is entirely beside the point.

Then again, if it's a disk hardware cache, he certainly isn't comparing
apples to apples on the other side of the controller; I suspect, however,
that this is not the case.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------