home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8610 < prev    next >
Encoding:
Text File  |  1992-11-08  |  3.0 KB  |  73 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!ukma!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad
  3. From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
  4. Subject: Re: bonnie i/o test results
  5. Message-ID: <1992Nov8.152611.26176@ntuix.ntu.ac.sg>
  6. Organization: Nanyang Technological University - Singapore
  7. X-Newsreader: TIN [version 1.1 PL6]
  8. References: <CGD.92Nov6232822@eden.CS.Berkeley.EDU>
  9. Date: Sun, 8 Nov 1992 15:26:11 GMT
  10. Lines: 61
  11.  
  12. Chris G. Demetriou (cgd@eden.CS.Berkeley.EDU) wrote:
  13. : 
  14. : LOOK, I'M SURE I'M NOT THE ONLY ONE WHO'S SICK OF SEEING BENCHMARKS WITH
  15. : ABSOLUTELY NO TECHNICAL MERIT.
  16.  
  17. No benchmark is perfect but at least we have figures. I'm fed up of people 
  18. who only say but do not produce any figure. Those who say the most does not
  19. mean that they are right.
  20. : 
  21. : PLEASE, before posting any more benchmarks:
  22. :     (1) learn about disk architecture.
  23. :         If you knew anything about it, you'd know
  24. :         that seek time is *disk* dependent, not
  25. :         controller dependent.
  26. I recommend you read more about controller architecture. John Bass article
  27. is a starter.
  28. : 
  29. :     (2) run the benchmarks on "equivalent" hardware.
  30. :         for instance, Maxtor 200M IDE vs. Maxtor 200M SCSI
  31. :         (i'd to the SCSI benchmark for you, but the only
  32. :         Maxtor 200M SCSI I have kicked off a few months ago...)
  33. : 
  34. Only if you are into stupid wasteful theoretical study. If you want to maximse,
  35. you worth, just test on what is available, for your particular application.
  36.  
  37. I did not state any conclusion for various reasons. It takes too long.
  38. bonnie is better in giving you the microprocessor load. It helps to have
  39. fast microporcessors, as in the case of Julian.
  40.  
  41. The only easy conclusion is that Julian i/o system is not as good as our
  42. i/o 486/33 system, although it is an EISA SCSI system.
  43.     I'm not sure about the reasons but I suspect it is due to the
  44. fragmentation. 
  45.  
  46. 486/33 Maxtor 200M IDE
  47.               -------Sequential Output-------- ---Sequential Input-- --Random--
  48.               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
  49. Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  50.            16   363 66.8   353  6.2   221 10.3   440 90.0   486  9.3  28.1  5.2
  51.  
  52. This 1Mbyte test is actually testing the efficiency of your buffer cache. I'm
  53. not sure how large the buffer cache is in 386bsd.
  54.     Linux integrated buffer/user space cache design is a big win here
  55. but nobody has come up with any figure.
  56.     Some e-mail me in saying that he can get 5Mbyte/second. It is faster
  57. than any workstation that I've tested. However I do not trust it so much
  58. until he posts the complete test details.
  59.  
  60.               -------Sequential Output-------- ---Sequential Input-- --Random--
  61.               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
  62. Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
  63.             1   504 94.6   332  6.5   182  7.8   346 67.6   441  9.5 107.8 17.4
  64.  
  65.  
  66.  
  67. --
  68. Othman bin Ahmad, School of EEE,
  69. Nanyang Technological University, Singapore 2263.
  70. Internet Email: eoahmad@ntuix.ntu.ac.sg
  71. Bitnet Email: eoahmad@ntuvax.bitnet
  72.  
  73.