home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / lang / asm / 514 < prev    next >
Encoding:
Internet Message Format  |  1992-12-27  |  3.2 KB
  1. Xref: sparky alt.lang.asm:514 comp.sys.ibm.pc.hardware:34334
  2. Newsgroups: alt.lang.asm,comp.sys.ibm.pc.hardware
  3. Path: sparky!uunet!munnari.oz.au!bruce.cs.monash.edu.au!monu6!daneel.rdt.monash.edu.au!tooraj
  4. From: tooraj@daneel.rdt.monash.edu.au (Tooraj Enayati)
  5. Subject: Re: DRAM refresh rates
  6. Message-ID: <tooraj.725591998@daneel.rdt.monash.edu.au>
  7. Sender: news@monu6.cc.monash.edu.au (Usenet system)
  8. Organization: Monash University, Melb., Australia.
  9. References: <1992Dec15.205835.643@zooid.guild.org> <1gske7INNgje@coli-gate.coli.uni-sb.de> <1992Dec27.105039.25690@microsoft.com>
  10. Date: Tue, 29 Dec 1992 01:19:58 GMT
  11. Lines: 51
  12.  
  13. chuckst@microsoft.com (Chuck Strouss) writes:
  14.  
  15. >In article <1gske7INNgje@coli-gate.coli.uni-sb.de> chbl@sbustd.rz.uni-sb.de (Christian Blum) writes:
  16. >>
  17. >>No way this will work. The refresh rate is set to 18.2 per second; since
  18. >>there are 512 rows to refresh, this means every bit in your computer's
  19. >>DRAM is refreshed every 20 seconds! There are DRAMS that survive 15ms
  20. >>without being refreshed, but a 70ns DRAM can't take it. Try about 10ms
  21. >>......
  22.  
  23. >It is surprising how long some DRAMs can go without refresh.  For
  24. >production systems, you must believe the manufacturers worst-case
  25. >specs, but DRAMs rarely need to be refreshed that often.
  26.  
  27. >A while back, I was working on the software for a computer system that
  28. >did its DRAM refresh with a software interrupt -- it only took about
  29. >5% of the CPU time.  At first, we had a bug in our refresh code, but
  30. >the system was still working remarkably well.  Tracing down another bug
  31. >revealed that we weren't refreshing at all, except for the natural
  32. >refreshing that came from the execution of code.
  33.  
  34. >Once we got the refresh working, we decided to determine exactly
  35. >how slow we could refresh and still have the system work.  We made
  36. >sure that the CPU was executing in a tight loop the rest of the time,
  37. >so that normal execution wasn't refreshing.
  38.  
  39. >Turns out the particular DRAMs we were using, at the temperatures
  40. >we were running, held their contents just fine with a 1-2 second
  41. >refresh rate.  They started failing a bit at 5 sec, and were
  42. >still 80% correct after 15 sec.
  43.  
  44. >We expanded our experiments a bit, and tried DRAMs from different
  45. >manufacturers, and also tried different temperatures.  There
  46. >were remarkable differences with both parameters.  We ended up
  47. >taking the full 5% CPU hit requirred to meet the manufacturers'
  48. >specs, which I think is a good decision for anybody who is tempted
  49. >to play around with refresh rates.
  50.  
  51. Ther are couple of files at simtel-20 (or its mirrors) under sysutl
  52. called qram.zip and fastram.zip (or maybe .arc) that let you play
  53. with the DRAM refresh rate and results in 5% to 10% CUP speed increase.
  54.  
  55. I managed to increse my CPU speed from 16.2Mhz to 17.33Mhz (checked it
  56. out using Landmark SPEED200). Interesting enough the video speeds up to
  57. and i can see inprovement when Windows is redrawing the screen.
  58.  
  59. -- 
  60. ==============================================================================
  61. Tooraj Enayati     Melbourne     Australia     tooraj@daneel.rdt.monash.edu.au
  62. Monash University       Robotic and Digital Technology       (Graduate/Alumni)
  63. ==============================================================================
  64.