From: rcd@raven.eklektix.com (Dick Dunn)
Subject: Re: bonnie i/o test results
Organization: eklektix - Boulder, Colorado
Date: Sun, 8 Nov 1992 05:41:54 GMT

cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>LOOK, I'M SURE I'M NOT THE ONLY ONE WHO'S SICK OF SEEING BENCHMARKS WITH
>ABSOLUTELY NO TECHNICAL MERIT.

Gosh, yes, but aim a bit more carefully, lest your own analysis come out
worse than the bad benchmark you're trying to criticize.

Chris quotes eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) on "bonnie" results;
I've compressed back to 80 col:
>   Julian 486/50 16M RAM, bustek SCSI-2 disk,
>	 -------Sequential Output-------- ---Sequential Input-- --Random--
>	 -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
>...   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
>      32   405 48.2   389  8.4   152  5.6   505 53.1   461 10.3  20.0  5.0
>   My machine 386/25 8M RAM , IDE Maxtor 200M disk,
>	 -------Sequential Output-------- ---Sequential Input-- --Random--
>	 -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
>...   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
>      16   121 99.2   350 15.6   190 17.7   108 99.8   454 16.4  25.9  8.9
>...Just look at the Random seek figure, the smaller IDE is faster ...
...
>in terms of reading and writing, as you can see from your above stats,
>Julian's SCSI disk generally kicks your IDE disk's butt.

No, in terms of reading and writing, as you can see from the above stats, a
486/50 has a faster CPU than a 386/25.  (pause for astonishment to subside)
You see the 386/25 eating it on per-char sequential I/O--that's the time
it spends in stdio shoving characters around.  Your clue is the 99.2% and
99.8% CPU utilization figures.  stdio time is an important aspect of over-
all system performance with C programs, but the time spent in getc/putc
really doesn't tell you a lot about the disk system.

Look at the block I/O and rewrite figures; you see the two systems incon-
clusively different.  The CPU time is, of course, higher for the machine
with the slower CPU.  Here, Chris's later point kicks in: the benchmarks
aren't being run on comparable hardware, so you can't learn much.

>		If you knew anything about it, you'd know
>		that seek time is *disk* dependent, not
>		controller dependent.

Come on, Chris...you can do better than that!  The essence of your point is
correct; however, the rate at which the overall system can do seeks is
dependent on disk *and* controller.  If the SCSI controller adds nontrivial
command overhead, it *will* affect random I/O performance.  Consider your
example of a disk with 12 ms average seek--that's for 1/3 of the max seek;
you can bet (or hope!) that even a large test file will have good locality,
hence shorter random seek times within the file than the disk average.  A
SCSI controller can add most of a millisecond to the command-processing
time (compared to IDE).  That's significant in the random seek rate of the
overall system as measured in this benchmark.

>	(2) run the benchmarks on "equivalent" hardware.

Amen to that one.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.
Newsgroups: comp.unix.bsd