Editing Dynamic random-access memory (section)

===Refresh rate===
{{Main|Memory refresh}}
{{See also|#Security}}

Typically, manufacturers specify that each row must be refreshed every 64&nbsp;ms or less, as defined by the [[JEDEC]] standard.

Some systems refresh every row in a burst of activity involving all rows every 64&nbsp;ms. Other systems refresh one row at a time staggered throughout the 64&nbsp;ms interval. For example, a system with 2<sup>13</sup>&nbsp;=&nbsp;8,192 rows would require a staggered [[refresh rate]] of one row every 7.8&nbsp;μs which is 64&nbsp;ms divided by 8,192 rows. A few real-time systems refresh a portion of memory at a time determined by an external timer function that governs the operation of the rest of a system, such as the [[vertical blanking interval]] that occurs every 10–20&nbsp;ms in video equipment.

The row address of the row that will be refreshed next is maintained by external logic or a [[Counter (digital)|counter]] within the DRAM. A system that provides the row address (and the refresh command) does so to have greater control over when to refresh and which row to refresh. This is done to minimize conflicts with memory accesses, since such a system has both knowledge of the memory access patterns and the refresh requirements of the DRAM. When the row address is supplied by a counter within the DRAM, the system relinquishes control over which row is refreshed and only provides the refresh command. Some modern DRAMs are capable of self-refresh; no external logic is required to instruct the DRAM to refresh or to provide a row address.

Under some conditions, most of the data in DRAM can be recovered even if the DRAM has not been refreshed for several minutes.<ref>{{cite journal |url=https://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman_html/ |title=Lest We Remember: Cold Boot Attacks on Encryption Keys |archive-url=https://web.archive.org/web/20150105103510/https://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman_html/ |archive-date=2015-01-05 |author=Halderman |display-authors=etal |journal =USENIX Security |date=2008}}</ref>