home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8622 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  2.7 KB
  1. Xref: sparky comp.unix.bsd:8622 comp.os.linux:16078
  2. Newsgroups: comp.unix.bsd,comp.os.linux
  3. Path: sparky!uunet!munnari.oz.au!metro!ipso!runxtsa!bde
  4. From: bde@runx.oz.au (Bruce Evans)
  5. Subject: Re: IDE faster than SCSI-2
  6. Message-ID: <1992Nov8.072924.6374@runx.oz.au>
  7. Organization: RUNX Un*x Timeshare.  Sydney, Australia.
  8. References: <1992Nov5.080716.10386@ntuix.ntu.ac.sg> <1df7dqINN37o@tartarus.uwa.edu.au>
  9. Date: Sun, 8 Nov 92 07:29:24 GMT
  10. Lines: 46
  11.  
  12. In article <1df7dqINN37o@tartarus.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
  13. >Othman Ahmad (eoahmad@ntuix.ntu.ac.sg) wrote:
  14. >: [...]
  15. >:  JUlian's machine 
  16. >:  is a 50MHz EISA 486 with a 1.3GB drive attached via a Bustek 742a SCSI2
  17. >:  adapter. It has 16MB of ram. Part of the disk (about 200MB is taken up 
  18. >:  by mach2.6 and is unavailable to 386bsd.
  19. >: 
  20. >: I checked the load on this machine, it is very light. There is only another
  21. >: user apart from I.
  22. >: 
  23. >: iozone 1
  24. >: 
  25. >: Writing the 1 Megabyte file, 'iozone.tmp'...1.766667 seconds
  26. >              ^
  27. >          ^ This is useless. It tells no-one anything. A one meg
  28. >file should fit entirely in the cache. So unless BSD is braindead, and
  29. >doesn't cache (which I doubt), then you have just measured the cache
  30. >speed. On my 486/33, 8 meg ram, a 1 meg files get 10 megs per second. 
  31.  
  32. 1 MB in 1.76 seconds is way below the cache speed.  In fact it is quite
  33. likely to be a good estimate for actual disk speed.
  34.  
  35. Disk caching in 386BSD-0.1 is quite broken.  First, only 10% of memory is
  36. used for the disk+swap cache.  This is smaller than I like.  (Comments in
  37. the code say that only 5% of memory after the first 2MB are allocated to
  38. the cache, but due to bugs, 10% of all memory is allocated.  A fix has
  39. been posted.)  Second, only half of the 10% is used for the disk cache.
  40. (Some (usually all) of the other half is reserved for buffers for swapping.)
  41. Third, memory for each buffer is allocated twice, so only 2.5% of memory is
  42. used for the disk cache!  A fix is in Terry's patch kit.  Fourth, bugs
  43. in the caching algorithm caused the cache to thrash.  A fix is in the patch
  44. kit.  Fifth, another kernel limit requires limiting the initial 10%
  45. allocation to 256 buffers to avoid panics (the limit is in the patch kit).
  46. (I actually use a limit of 503 to get 251 disk buffers and 252 swap buffers.
  47. This is fairly safe because the system almost never swaps.)
  48.  
  49. >I don't know exactly what you measured, but it sure ain't disk speed.
  50.  
  51. It probably was disk speed!  I don't know exactly what the cache size
  52. is on Julian's system.  If the system has all the standard patches, it
  53. will have 128 disk buffers for a total cache size of about 512K if the
  54. file system has a block size of 4K.  That is consistent with the
  55. benchmark.
  56. -- 
  57. Bruce Evans  (bde@runx.oz.au)
  58.