Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!think.com!linus!agate!tfs.com!julian From: julian@tfs.com (Julian Elischer) Subject: Re: IDE vs SCSI-2 using iozone Message-ID: <1992Nov3.200355.9048@tfs.com> Organization: TRW Financial Systems, Berkeley, CA - 94704 References: <1992Nov2.085559.18528@ntuix.ntu.ac.sg> <a9nd02fU293D01@JUTS.ccc.amdahl.com> <1992Nov3.185543.22418@fcom.cc.utah.edu> Date: Tue, 3 Nov 1992 20:03:55 GMT Lines: 54 In article <1992Nov3.185543.22418@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >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. >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). before we get all excited here 8-) there is more information needed: The scsi driver queues more than one request to the board at a time which can sosmetime improve throughput, however in a single threaded pregram that cannot speed up the reading too much because the program has to wait for the data.. It can speed up the writing because of the write-behind nature of the unix filesystems. (you might see if iozone has fsync() after each write.) a big effect here is the filesystem blocksize. what is the blocksize for the filesystems in each case? it can make a big difference. I am not willing to even consider these numbers as meaningful unless you can also include the filesystem blocksize used ineach case. also we should be able to tune the fs in each case. There is no point in comparing two untuned filesystems.. The raw throughput for the SCSI drive mentionned is about 3MB/sec on 16K transfers so there's a lot of improvement possible if we look at those figures. I know some of the filesystems on ref are 4k filesystems and there is one 8k filesystem.. which did you use? Was the IDE filesystem a 4k filesystem? 8k? julian