Refresh Rate on DDR3

2,223 views
Skip to first unread message

FuturePlusSystems

unread,
Jul 10, 2015, 11:22:34 AM7/10/15
to rowhamme...@googlegroups.com
Folks,

Just a little note on REFRESH rates on DDR3.  The normal refresh rate is 7.8us.  This is the time between REFRESH commands issued from the memory controller to the individual RANKS of the DIMM or SODIMM (laptops).  The number I see being used in these discussions, 64ms or 32ms, is the Retention Cycle.  This is the time it takes for all banks to be refreshed.  You see when the memory controller issues the REF command the DRAM does not refresh all banks within the rank.  The DRAM refreshes only some of them.  However within 64ms (or 32ms what ever the setting is) the DRAM has to have refreshed them all.  At higher temperatures the spec says you have to double the refresh rate that is why that option is available.  It just so happens that its being used to refresh more frequently to prevent RH failures. 

Regards,
Barbara Aichinger
FuturePlus Systems

Mark Seaborn

unread,
Jul 10, 2015, 3:30:23 PM7/10/15
to rowhammer-discuss, FuturePlusSystems
Thanks for joining the mailing list!

On 10 July 2015 at 08:22, FuturePlusSystems <barb.ai...@futureplus.com> wrote:
Folks,

Just a little note on REFRESH rates on DDR3.  The normal refresh rate is 7.8us.  This is the time between REFRESH commands issued from the memory controller to the individual RANKS of the DIMM or SODIMM (laptops).  The number I see being used in these discussions, 64ms or 32ms, is the Retention Cycle.  This is the time it takes for all banks to be refreshed.  You see when the memory controller issues the REF command the DRAM does not refresh all banks within the rank.  The DRAM refreshes only some of them.

This Utah Arch blog post has a good description of that too:

It explains how refreshing a bank is divided into 8192 refresh operations.

I also wrote a tool which uses this knowledge to determine the refresh rate from an unprivileged process by timing memory accesses:

 
However within 64ms (or 32ms what ever the setting is) the DRAM has to have refreshed them all.  At higher temperatures the spec says you have to double the refresh rate that is why that option is available.  It just so happens that its being used to refresh more frequently to prevent RH failures.

Do you know what happens when a machine is configured to use a 2x refresh (32ms overall period) *and* is running at a higher temperature?  Does the memory controller switch to a 4x refresh rate (16ms overall period)?

It looks like that is what would happen based on reading Intel's documentation for configuring their memory controllers.  For example, these docs: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-u-y-processor-lines-vol-2-datasheet.pdf

It looks like these two aspects are independent:
  • The base refresh rate for use at normal temperatures -- the parameter tREFI.  The BIOS sets this on startup.
  • Whether the refresh rate is doubled from the normal rate at higher temperatures.  e.g. REFRESH_2X_MODE, REFRESH2X_LOG, REFRESH2X_STATUS, ENABLE_2X_REFRESH_INTERRUPT.  It looks like the memory controller is responsible for doubling the rate based on the temperature, so the CPU is not involved.
Cheers,
Mark

Barbara Aichinger

unread,
Jul 12, 2015, 11:33:37 AM7/12/15
to rowhamme...@googlegroups.com
On the question of a 4x refresh rate.  Personally I have never seen this.  However I can easily measure this if you can make a system that you think is doing this available to me.  In fact I can give you a listing of all the transactions on the memory bus for what ever code you would like to run.  We have traced the code that you posted.  You can load our tool's software on your system and then load the stored data file if you would like to see the Address/Command and Control traffic.

Barbara Aichinger
FuturePlus Systems
www.DDRDetective.com
www.FuturePlus.com
Barbara P.  Aichinger
Vice President 
New Business Development
FuturePlus Systems Corporation
wk:603-472-5905
www.FuturePlus.com
cell:603-548-5037
--
You received this message because you are subscribed to a topic in the Google Groups "rowhammer-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rowhammer-discuss/GEUfuYt3NyQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rowhammer-disc...@googlegroups.com.
To post to this group, send email to rowhamme...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rowhammer-discuss/CAL82V5Pu%2BQavacCsv0yzMAFyzjjZzuXDsYWdts7u5zYXXqQEcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages