Return to BSD News archive
Xref: sserve comp.unix.bsd:7633 comp.os.linux:15153 Newsgroups: comp.unix.bsd,comp.os.linux Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!sh.wide!kogwy!math-keio!mad From: mad@math.keio.ac.jp (MAEDA Atusi) Subject: Re: IDE faster than SCSI-2 In-Reply-To: eoahmad@ntuix.ntu.ac.sg's message of Fri, 6 Nov 1992 01: 25:10 GMT Message-ID: <MAD.92Nov7210246@amber.math.keio.ac.jp> Lines: 61 Sender: news@math.keio.ac.jp Nntp-Posting-Host: amber Reply-To: mad@math.keio.ac.jp Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan. References: <MAD.92Nov5204000@lettuce.math.keio.ac.jp> <1992Nov6.012510.12371@ntuix.ntu.ac.sg> Date: Sat, 7 Nov 1992 12:02:50 GMT In article <1992Nov6.012510.12371@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: >MAEDA Atusi (mad@math.keio.ac.jp) wrote: >: The file size of one megabyte is too short to get meaningful result. >: You are just measuring the speed of copying to/from buffer cache. > >You may be right there but remember that Julian's machine runs at 50Mhz, >whereas mine at 33Mhz. [deleted] > If you want a figure excluding the disk/buffer cache, take the read >figure. > If it were really all from buffer cache, then the write figure should >be much higher, equivalent to memory bandwidth, i.e. 25Mbyte/second. > Assuming 4 cycles of 50Mhz, 32 bit per cycle. Maybe yes, maybe no. The result includes buffer cache searching overhead (which increases with more buffer cache pages). 25Mbyte/sec is unrealistic, even when no real I/O is performed. System call of 1MB/512 = 2048 times can not be negligible. > buffer cache from 386bsd cannot be as large as 1 Mbyte. I'm surprised with this. I'm using Linux, which dynamically changes buffer cache size according to system usage. I oftenly observe the size of buffer cache grows over 4MB on my system (8MB RAM) with heavy I/O load. FYI, on my systems (486DX/33, 256K cache, 8MB RAM, 200MB IDE, running Linux 0.97pl6), IOZONE reports more than 5MB/sec given numbers smaller than 4MB. I wouldn't say my disk is 10 times faster than your SCSI-2 :-). If I switch my disk to SCSI-2 and run the same test, the result wouldn't be improved at all. >At least we are testing the efficiency of the use of buffer cache. >The latest version of iozone actually flushes the cache but I do not like this, >because that is not how we use unix file system. It does not measure realistic >situation. If the buffer cache never exceeds 1 MB in 386bsd, just one linkage or text formatting (with larege fonts) can easily flush the entire contents of buffer cache. And it's the usual way how we use unix file systems. Anyway, if you are testing the I/O speed in such a way, you can never tell about the difference between IDE and SCSI2, because disk speed is totally irrelevant. >: >: You should give numbers at least twice as large as your RAM size. >: >Actually I did that, but the figures are not informative. Not relevant to our >usual use. It confused more than it explains. > I advise people to ignore these "unrealistically high load". IOZONE *is* intended to be given larege numbers. Any other usage is out of consideration of the author and thus (I think) results are not very informative then. ;;; Keio University ;;; Faculty of Science and Technology ;;; Department of Math ;;; MAEDA Atusi (In Japan we write our family names first.) ;;; mad@math.keio.ac.jp