home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8577 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  3.4 KB
  1. Xref: sparky comp.unix.bsd:8577 comp.os.linux:15980
  2. Newsgroups: comp.unix.bsd,comp.os.linux
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!sun-barr!sh.wide!kogwy!math-keio!mad
  4. From: mad@math.keio.ac.jp (MAEDA Atusi)
  5. Subject: Re: IDE faster than SCSI-2
  6. In-Reply-To: eoahmad@ntuix.ntu.ac.sg's message of Fri, 6 Nov 1992 01: 25:10 GMT
  7. Message-ID: <MAD.92Nov7210246@amber.math.keio.ac.jp>
  8. Lines: 61
  9. Sender: news@math.keio.ac.jp
  10. Nntp-Posting-Host: amber
  11. Reply-To: mad@math.keio.ac.jp
  12. Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
  13. References: <MAD.92Nov5204000@lettuce.math.keio.ac.jp>
  14.     <1992Nov6.012510.12371@ntuix.ntu.ac.sg>
  15. Date: Sat, 7 Nov 1992 12:02:50 GMT
  16.  
  17. In article <1992Nov6.012510.12371@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
  18.  
  19.  >MAEDA Atusi (mad@math.keio.ac.jp) wrote:
  20.  >: The file size of one megabyte is too short to get meaningful result.
  21.  >: You are just measuring the speed of copying to/from buffer cache.
  22.  >
  23.  >You may be right there but remember that Julian's machine runs at 50Mhz,
  24.  >whereas mine at 33Mhz.
  25. [deleted]
  26.  >      If you want a figure excluding the disk/buffer cache, take the read
  27.  >figure.
  28.  >      If it were really all from buffer cache, then the write figure should
  29.  >be much higher, equivalent to memory bandwidth, i.e. 25Mbyte/second.
  30.  >      Assuming 4 cycles of 50Mhz, 32 bit per cycle.
  31.  
  32. Maybe yes, maybe no.  The result includes buffer cache searching
  33. overhead (which increases with more buffer cache pages).
  34. 25Mbyte/sec is unrealistic, even when no real I/O is performed.
  35. System call of 1MB/512 = 2048 times can not be negligible.
  36.  
  37.  >      buffer cache from 386bsd cannot be as large as 1 Mbyte.
  38.  
  39. I'm surprised with this.  I'm using Linux, which dynamically changes
  40. buffer cache size according to system usage.  I oftenly observe the
  41. size of buffer cache grows over 4MB on my system (8MB RAM) with heavy
  42. I/O load.
  43.  
  44. FYI, on my systems (486DX/33, 256K cache, 8MB RAM, 200MB IDE, running
  45. Linux 0.97pl6), IOZONE reports more than 5MB/sec given numbers smaller
  46. than 4MB.  I wouldn't say my disk is 10 times faster than your SCSI-2 :-).
  47. If I switch my disk to SCSI-2 and run the same test, the result wouldn't
  48. be improved at all.
  49.  
  50.  >At least we are testing the efficiency of the use of buffer cache.
  51.  >The latest version of iozone actually flushes the cache but I do not like this,
  52.  >because that is not how we use unix file system. It does not measure realistic
  53.  >situation.
  54.  
  55. If the buffer cache never exceeds 1 MB in 386bsd, just one linkage or
  56. text formatting (with larege fonts) can easily flush the entire
  57. contents of buffer cache.  And it's the usual way how we use unix file
  58. systems.  Anyway, if you are testing the I/O speed in such a way, you
  59. can never tell about the difference between IDE and SCSI2, because
  60. disk speed is totally irrelevant.
  61.  
  62.  >: 
  63.  >: You should give numbers at least twice as large as your RAM size.
  64.  >: 
  65.  >Actually I did that, but the figures are not informative. Not relevant to our
  66.  >usual use. It confused more than it explains.
  67.  >      I advise people to ignore these "unrealistically high load".
  68.  
  69. IOZONE *is* intended to be given larege numbers.  Any other usage is
  70. out of consideration of the author and thus (I think) results are not
  71. very informative then.
  72.  
  73. ;;;  Keio University
  74. ;;;    Faculty of Science and Technology
  75. ;;;      Department of Math
  76. ;;;        MAEDA Atusi (In Japan we write our family names first.)
  77. ;;;        mad@math.keio.ac.jp
  78.