home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.bsd:8508 comp.os.linux:15845
- Newsgroups: comp.unix.bsd,comp.os.linux
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wupost!gumby!yale!yale.edu!jvnc.net!nuscc!ntuix!eoahmad
- From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
- Subject: Re: IDE faster than SCSI-2
- Message-ID: <1992Nov6.012510.12371@ntuix.ntu.ac.sg>
- Organization: Nanyang Technological University - Singapore
- X-Newsreader: TIN [version 1.1 PL6]
- References: <MAD.92Nov5204000@lettuce.math.keio.ac.jp>
- Date: Fri, 6 Nov 1992 01:25:10 GMT
- Lines: 30
-
- 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.
- buffer cache from 386bsd cannot be as large as 1 Mbyte.
- 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 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.
- :
- : 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".
- However I'll do it anyway.
-
- --
- Othman bin Ahmad, School of EEE,
- Nanyang Technological University, Singapore 2263.
- Internet Email: eoahmad@ntuix.ntu.ac.sg
- Bitnet Email: eoahmad@ntuvax.bitnet
-
-