home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4797 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.7 KB
  1. Path: sparky!uunet!olivea!xenitec!news
  2. From: belal@sco.COM (Bela Lubkin)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: Performace degradation under SCO
  5. Message-ID: <9212221312.aa05623@scoke.sco.COM>
  6. Date: 22 Dec 92 21:12:19 GMT
  7. Sender: news@xenitec.on.ca (xenitec.on.ca News Administrator)
  8. Organization: [resent by] The SCOGEN gateway and Propagation Society
  9. Lines: 45
  10. Resent-From: mmdf@xenitec.on.ca
  11. Submit-To: scogen@xenitec.on.ca
  12. Precedence: bulk
  13.  
  14. > The problem may not be related to kernel parameters at all. Many ISA bus
  15. > motherboards will exhibit major speed degradation when you go past 16 MB
  16. > of main store.
  17. > 
  18. > The reason, simplified, is that the ISA bus has 24 address lines for doing
  19. > memory access, which means it can only directly address 16MB. After that,
  20. > when UNIX tries to do DMA, it must copy down or page memory chunks to a
  21. > space below 16 MB. This is very slow. Some MB manufactures have worked 
  22. > around this but for the most part, my experience has been that stock and 
  23. > standard MB's ( read; the ones that work right) will have this limitation.
  24.  
  25. This is mostly a red herring: first, SCO UNIX 3.2v4/ODT 2.0 knows
  26. whether your host adapter/bus combination can DMA above 16MB.  It goes
  27. to a lot of effort to make sure that things that might need to be DMA'd
  28. to/from, like the buffer cache and kernel .data & .bss areas, are stored
  29. in DMAable memory, while things that will not need to be DMA'd to, like
  30. kernel .text, are stored in non-DMAable memory if any is available.
  31. Second, if you compare modern processor and memory speeds to disk
  32. speeds, you'll find that the cost of doing the memory transfer is
  33. miniscule compared to the disk I/O.  Let's just suppose that you're
  34. running at 33MHz and that it takes 20 cycles per byte (a wildly
  35. pessimistic estimate) to copy memory.  So to copy a 512-byte buffer
  36. takes 512*20 = 10240 cycles, or 10240/33 uSec, or .31 milliseconds.
  37. This is less than 1/50th of a single disk rotation on a typical drive!
  38. Third, this only affects disk I/O, it shouldn't affect programs that are
  39. running in memory (except when other processes are doing disk I/O, they
  40. will have a small amount less CPU time to play with).
  41.  
  42. (The .31ms result is so low -- so much lower than I expected -- that I'm
  43. wondering if I didn't blow a step somewhere.  Anyone see a mistake?)
  44.  
  45. > Before ODT came out, we didn't see this often because > 16MB of memory
  46. > was the exception rather than the rule on x86 hardware. ODT's hunger
  47. > for main memory has pushed this ISA amonaly into many unsuspecting 
  48. > faces. 
  49. > 
  50. > Prove this by yanking the top 16MB out, and seeing if you still have
  51. > the problem. Don't let swapping (if any) fog your results.
  52. > 
  53. > Fix == EISA
  54.  
  55. Ok, but pulling the top 16MB will also fix the not-enough-cache problem
  56. that's *really* making the system slow.  ;-}
  57.  
  58. >Bela<
  59.