Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: bonnie i/o test results
Message-ID: <1992Nov8.152611.26176@ntuix.ntu.ac.sg>
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
References: <CGD.92Nov6232822@eden.CS.Berkeley.EDU>
Date: Sun, 8 Nov 1992 15:26:11 GMT
Lines: 61
Chris G. Demetriou (cgd@eden.CS.Berkeley.EDU) wrote:
:
: LOOK, I'M SURE I'M NOT THE ONLY ONE WHO'S SICK OF SEEING BENCHMARKS WITH
: ABSOLUTELY NO TECHNICAL MERIT.
No benchmark is perfect but at least we have figures. I'm fed up of people
who only say but do not produce any figure. Those who say the most does not
mean that they are right.
:
: PLEASE, before posting any more benchmarks:
: (1) learn about disk architecture.
: If you knew anything about it, you'd know
: that seek time is *disk* dependent, not
: controller dependent.
I recommend you read more about controller architecture. John Bass article
is a starter.
:
: (2) run the benchmarks on "equivalent" hardware.
: for instance, Maxtor 200M IDE vs. Maxtor 200M SCSI
: (i'd to the SCSI benchmark for you, but the only
: Maxtor 200M SCSI I have kicked off a few months ago...)
:
Only if you are into stupid wasteful theoretical study. If you want to maximse,
you worth, just test on what is available, for your particular application.
I did not state any conclusion for various reasons. It takes too long.
bonnie is better in giving you the microprocessor load. It helps to have
fast microporcessors, as in the case of Julian.
The only easy conclusion is that Julian i/o system is not as good as our
i/o 486/33 system, although it is an EISA SCSI system.
I'm not sure about the reasons but I suspect it is due to the
fragmentation.
486/33 Maxtor 200M IDE
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
16 363 66.8 353 6.2 221 10.3 440 90.0 486 9.3 28.1 5.2
This 1Mbyte test is actually testing the efficiency of your buffer cache. I'm
not sure how large the buffer cache is in 386bsd.
Linux integrated buffer/user space cache design is a big win here
but nobody has come up with any figure.
Some e-mail me in saying that he can get 5Mbyte/second. It is faster
than any workstation that I've tested. However I do not trust it so much
until he posts the complete test details.
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
1 504 94.6 332 6.5 182 7.8 346 67.6 441 9.5 107.8 17.4
--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet