home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8600 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.4 KB  |  69 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!purdue!yuma!csn!raven!rcd
  3. From: rcd@raven.eklektix.com (Dick Dunn)
  4. Subject: Re: bonnie i/o test results
  5. Message-ID: <1992Nov8.054154@eklektix.com>
  6. Organization: eklektix - Boulder, Colorado
  7. References: <1992Nov6.144749.26760@ntuix.ntu.ac.sg> <CGD.92Nov6232822@eden.CS.Berkeley.EDU>
  8. Date: Sun, 8 Nov 1992 05:41:54 GMT
  9. Lines: 58
  10.  
  11. cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
  12. >LOOK, I'M SURE I'M NOT THE ONLY ONE WHO'S SICK OF SEEING BENCHMARKS WITH
  13. >ABSOLUTELY NO TECHNICAL MERIT.
  14.  
  15. Gosh, yes, but aim a bit more carefully, lest your own analysis come out
  16. worse than the bad benchmark you're trying to criticize.
  17.  
  18. Chris quotes eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) on "bonnie" results;
  19. I've compressed back to 80 col:
  20. >   Julian 486/50 16M RAM, bustek SCSI-2 disk,
  21. >     -------Sequential Output-------- ---Sequential Input-- --Random--
  22. >     -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
  23. >...   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  24. >      32   405 48.2   389  8.4   152  5.6   505 53.1   461 10.3  20.0  5.0
  25. >   My machine 386/25 8M RAM , IDE Maxtor 200M disk,
  26. >     -------Sequential Output-------- ---Sequential Input-- --Random--
  27. >     -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
  28. >...   MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  29. >      16   121 99.2   350 15.6   190 17.7   108 99.8   454 16.4  25.9  8.9
  30. >...Just look at the Random seek figure, the smaller IDE is faster ...
  31. ...
  32. >in terms of reading and writing, as you can see from your above stats,
  33. >Julian's SCSI disk generally kicks your IDE disk's butt.
  34.  
  35. No, in terms of reading and writing, as you can see from the above stats, a
  36. 486/50 has a faster CPU than a 386/25.  (pause for astonishment to subside)
  37. You see the 386/25 eating it on per-char sequential I/O--that's the time
  38. it spends in stdio shoving characters around.  Your clue is the 99.2% and
  39. 99.8% CPU utilization figures.  stdio time is an important aspect of over-
  40. all system performance with C programs, but the time spent in getc/putc
  41. really doesn't tell you a lot about the disk system.
  42.  
  43. Look at the block I/O and rewrite figures; you see the two systems incon-
  44. clusively different.  The CPU time is, of course, higher for the machine
  45. with the slower CPU.  Here, Chris's later point kicks in: the benchmarks
  46. aren't being run on comparable hardware, so you can't learn much.
  47.  
  48. >        If you knew anything about it, you'd know
  49. >        that seek time is *disk* dependent, not
  50. >        controller dependent.
  51.  
  52. Come on, Chris...you can do better than that!  The essence of your point is
  53. correct; however, the rate at which the overall system can do seeks is
  54. dependent on disk *and* controller.  If the SCSI controller adds nontrivial
  55. command overhead, it *will* affect random I/O performance.  Consider your
  56. example of a disk with 12 ms average seek--that's for 1/3 of the max seek;
  57. you can bet (or hope!) that even a large test file will have good locality,
  58. hence shorter random seek times within the file than the disk average.  A
  59. SCSI controller can add most of a millisecond to the command-processing
  60. time (compared to IDE).  That's significant in the random seek rate of the
  61. overall system as measured in this benchmark.
  62.  
  63. >    (2) run the benchmarks on "equivalent" hardware.
  64.  
  65. Amen to that one.
  66. -- 
  67. Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
  68.     ...Simpler is better.
  69.