home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / pcclone / 32bit / 927 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  1.4 KB
  1. Path: sparky!uunet!pipex!bnr.co.uk!uknet!mcsun!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
  3. Newsgroups: comp.unix.pc-clone.32bit
  4. Subject: Which motherboard?
  5. Message-ID: <1992Dec30.132843.25162@klaava.Helsinki.FI>
  6. Date: 30 Dec 92 13:28:43 GMT
  7. Organization: University of Helsinki
  8. Lines: 21
  9.  
  10. This is just a follow-up to the discussion about non-caching in the
  11. 16MB+ range - as I hoped, getting the bigger cache solved the problem. 
  12. So, if you have problems with some of your memory seeming much slower
  13. than it should be, upgrading your external cache to the maximum amount
  14. may well help you.  On a 486, inability to cache may result in a
  15. slowdown of more than one order of magnitude (I saw 20 times slower
  16. execution in a non-cached area). 
  17.  
  18. The particular chipset on the motherboard I have is by Contaq,
  19. specifically 82C591/82C592.  With a 64kB cache, only the low 16MB is
  20. cached, while a 256kB cache allows for caching the full memory area
  21. (well, I can try only up to 20MB, but I'd assume it gets cached at least
  22. up to 32MB, and probably to the full 64MB that the motherboard
  23. supports).  The problem is not mentioned in the motherboard manual. 
  24.  
  25. Hope this may solve similar problems by others: the reasons for these
  26. slowdowns may not be immediately obvious, especially if the machine
  27. seems to run DOS etc fine (at least DOS very seldom uses the 16MB+ area
  28. heavily, so you'll probably never see the problem very clearly). 
  29.  
  30.         Linus
  31.