Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!uunet!cs.utexas.edu!sun-barr!ames!purdue!yuma!csn!raven!rcd From: rcd@raven.eklektix.com (Dick Dunn) Subject: Re: bonnie i/o test results Message-ID: <1992Nov8.054154@eklektix.com> Organization: eklektix - Boulder, Colorado References: <1992Nov6.144749.26760@ntuix.ntu.ac.sg> <CGD.92Nov6232822@eden.CS.Berkeley.EDU> Date: Sun, 8 Nov 1992 05:41:54 GMT Lines: 58 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.