home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / lang / asm / 512 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  2.2 KB
  1. Xref: sparky alt.lang.asm:512 comp.sys.ibm.pc.hardware:34296
  2. Newsgroups: alt.lang.asm,comp.sys.ibm.pc.hardware
  3. Path: sparky!uunet!microsoft!hexnut!chuckst
  4. From: chuckst@microsoft.com (Chuck Strouss)
  5. Subject: DRAM refresh rates
  6. Message-ID: <1992Dec27.105039.25690@microsoft.com>
  7. Date: 27 Dec 92 10:50:39 GMT
  8. Organization: Microsoft Corporation
  9. References: <1992Dec15.205835.643@zooid.guild.org> <1gske7INNgje@coli-gate.coli.uni-sb.de>
  10. Lines: 36
  11.  
  12. In article <1gske7INNgje@coli-gate.coli.uni-sb.de> chbl@sbustd.rz.uni-sb.de (Christian Blum) writes:
  13. >
  14. >No way this will work. The refresh rate is set to 18.2 per second; since
  15. >there are 512 rows to refresh, this means every bit in your computer's
  16. >DRAM is refreshed every 20 seconds! There are DRAMS that survive 15ms
  17. >without being refreshed, but a 70ns DRAM can't take it. Try about 10ms
  18. >......
  19.  
  20. It is surprising how long some DRAMs can go without refresh.  For
  21. production systems, you must believe the manufacturers worst-case
  22. specs, but DRAMs rarely need to be refreshed that often.
  23.  
  24. A while back, I was working on the software for a computer system that
  25. did its DRAM refresh with a software interrupt -- it only took about
  26. 5% of the CPU time.  At first, we had a bug in our refresh code, but
  27. the system was still working remarkably well.  Tracing down another bug
  28. revealed that we weren't refreshing at all, except for the natural
  29. refreshing that came from the execution of code.
  30.  
  31. Once we got the refresh working, we decided to determine exactly
  32. how slow we could refresh and still have the system work.  We made
  33. sure that the CPU was executing in a tight loop the rest of the time,
  34. so that normal execution wasn't refreshing.
  35.  
  36. Turns out the particular DRAMs we were using, at the temperatures
  37. we were running, held their contents just fine with a 1-2 second
  38. refresh rate.  They started failing a bit at 5 sec, and were
  39. still 80% correct after 15 sec.
  40.  
  41. We expanded our experiments a bit, and tried DRAMs from different
  42. manufacturers, and also tried different temperatures.  There
  43. were remarkable differences with both parameters.  We ended up
  44. taking the full 5% CPU hit requirred to meet the manufacturers'
  45. specs, which I think is a good decision for anybody who is tempted
  46. to play around with refresh rates.
  47.  
  48.