• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Looking for an explination of memory timings?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

Johnny5

Member
Joined
Jan 28, 2011
Hello, I am new to forums so hopefully this hasn't been discussed in great detail, however I can't find a good answer anywhere (on the net in general) so I thought I'd just ask.

Right now, I am running 6gigs of mushkin DDR3 RAM rated at 1600 on a Asus Rampage III Extreme with an i7 950. I've been trying to push my overclock to 4.4 with a base clock of 210 and a cpu multiplier of 21. I can get it stable at 207. Anyway, at around 208 and up I start receiving 03b Machine check exception and non page default bsods which lead me to believe they are memory related bsods. I'm at near 1.4 QPI and 1.66 DRAM voltage and was hoping to avoid pushing the power much further (this is all on water). I know that loosening the timings will help, but I can't find a specific explanation on what each of the timings actually do and the best way to go about adjusting their settings. This is what I have to work with:
>DRAM Timing Control--------------------------
CAS# Latency 9 [8]
RAS# to CAS# Delay 9 [8]
RAS# PRE Time 9 [7]
RAS# ACT Time 24 [21]
RAS# to RAS# Delay 6 [AUTO]
REF Cycle Time 82 [82]
WRITE Recovery Time 15 [AUTO]
READ to PRE Time 9 [AUTO]
FOUR ACT WIN Time 31 [AUTO]
Back-To-BackCAS# Delay 0 [Auto]

Timing Mode 1N [1N]
Round Trip Latency on CHA [AUTO]
Round Trip Latency on CHB [AUTO]
Round Trip Latency on CHC [AUTO]

WRITE To READ Delay(DD) 8 [Auto]
WRITE To READ Delay(DR) 8 [Auto]
WRITE To READ Delay(SR) 18 [Auto]
READ To WRITE Delay(DD) 7 [Auto]
READ To WRITE Delay(DR) 7 [Auto]
READ To WRITE Delay(SR) 7 [Auto]
READ To READ Delay(DD) 7 [Auto]
READ To READ Delay(DR) 6 [Auto]
READ To READ Delay(SR) 4 [Auto]
WRITE To WRITE Delay(DD) 8 [Auto]
WRITE To WRITE Delay(DR) 8 [Auto]
WRITE To WRITE Delay(SR) 18 [Auto]

Also, I was wondering if there is any advantage/danger in adjusting the individual DRAM ref voltage for the channels?

If anyone can give any sort of guidance or direct me somewhere that can breaks it down I'd be greatly appreciative.

Thanks
 
:welcome: to OCForums!

I'm assuming you've tried plenty of vcore settings too. Have you tried reducing the RAM multiplier to as low as possible while OCing the CPU? That will eliminate the RAM from the instability equation. You can try increasing the PCIe Frequency, it's usually needed for high bclk.

Timing descriptions are below, wrapped in [code][/code] to reduce its massive size...lol.

Code:
[B]-Cas# Latency (tCL).[/B]
Number of clocks that elapses between the memory controller telling
  the memory module to access a particular column in the current row,
and the data from that column being read from the module's output pins.
[B]
-RAS# to CAS# Delay (tRCD).[/B]
Controls the number of clocks inserted between a row activate command
and a read or write command to that row. Last Intel chipset (965 and P35)
allow to change RAS# to CAS# Read Delay and RAS# to CAS# Write Delay separately                  
[B]
-RAS# Precharge (tRP). [/B]
Controls the number of clocks that are inserted between a row precharge
command and an activate command to the same rank.                  
[B]
-Activate to Precharge delay (tRAS). [/B]
Number of clocks taken between a bank active command and issuing the
  precharge command. Usually, tRAS=tCL + tRCD + 2.                  
[B]
-Row Cycle Time (tRC). [/B]
Determines the minimum number of clock cycles a memory row takes to
complete a full cycle, from row activation up to the precharging of
the active row. For optimal performance, use the lowest value you can,
according to the tRC = tRAS + tRP formula. For example:
if your memory module's tRAS is 7 clock cycles and its tRP is 4 clock cycles,
then the row cycle time or tRC should be 11 clock cycles.                  
[B]
-Refresh to Activate Delay / Refresh Cycle Time (tRFC). [/B]
Determines the number of clock measured from a Refresh command (REF)
until the first Activate command (ACT) to the same rank                  
[B]
-Refresh Mode Select (RMS) / Refresh Period (tREF). [/B]
Determines at what rate refreshes will be executed. Contrary to other timings,
higher value is better for performance.                   
[B]
-Command Rate / Command per Clock (1T/2T). [/B]
Delay between when a memory chip is selected and when the first active
command can be issued. The factors that determine whether a memory
subsystem can tolerate a 1T command rate are many, including the number
of memory banks, the number of DIMMs present, and the quality of the DIMMs.               
[B]
-Performance Level / Read Delay (tRD).[/B]
tRD is the number of memory clocks from DRAM Chip Select# assert
to Host Data Ready# assertion on the FSB.
  Hight influence on performance and stability.                  
[B]
-Write to Precharge Delay / Write Recovery Time (tWR). [/B]
-Write Recovery time is an internal dram timing, values are usually 3 to 10.
It specifies the amount of delay (in clock cycles) that must elapse after the
completion of a valid write operation, before an active bank can be precharged.
  -Write to Precharge is a command delay, and is calculed as:
Write to Precharge = tCL - 1 +BL/2 + tWR.
BL(Burst Length) practically always 8.                   
[B]
-Write to Read command Delay / Write to Read Delay (tWTR). [/B]
-Write to Read delay is an internal dram timing, values are usually 2 to 8.
Specifie the number of clock between the last valid write operation and the next
read command to the same internal bank
  -Write to Read command is a command delay, and is calculed as:
Write to Read = tCL - 1 +BL/2 + tWTR.
BL(Burst Length) practically always 8.                  
[B]
-Activate to Activate delay (tRRD). [/B]
Number of clocks between two row activate in different banks of the same rank.                  
[B]
-Read to Precharge delay (tRTP). [/B]
Number of clocks that are inserted between a read command to a row
pre-charge command to the same rank.                  
[B]
-Read to Write delay (tRTW). [/B]
Number of clocks that are inserted between a read command to a write
  command to the same rank.                   
[B]
-Round Trip Latency. [/B]
Number of Uncore clocks that are inserted for Read data after
  a Read Cas# is send to a DIMM.                   
[B]
-Four Activate Window (tFAW). [/B]
Specifies the time window in wich four activates are allowed the same rank.                   
[B]
-Precharge to Precharge delay (tPTP). [/B]
Number of clocks that are inserted between two Precharge command in
  different banks of the same rank.                  
[B]
-Write-Read Command Spacing (tWR-RD). [/B]
This field determines the number of turn-around clocks on the data bus needs
to be inserted between write command and a subsequent read command on Different Rank.                
[B]
-Read-Write Command Spacing (tRD-WR). [/B]
This field determines the number of turn-around clocks on the data bus needs
  to be inserted between read command and a subsequent write command on Different Rank.                
[B]
-Write-Write Command Spacing (tWR-WR).[/B]
  This field controls the turnaround time on the DQ bus for WR-WR sequence to
different ranks in one channel.
[B]
-Force Auto Precharge.[/B]
  When enabled, force auto Precharging with every read or write command.
This may be preferred in situation where powers savings is favored over performance.
[B]
-Maximum Asynchronous Latency.[/B]
  Specify the maximum round trip latency in the system from the processeur to
the DRAM devices and back.
[B]
-Maximum Read Latency.[/B]
  Specify the maximum round trip latency in the system from the processeur to
the DRAM devices and back. This time is specified in NorthBridge clock and
includes the asynchronous and synchronous latencies.                
[B]
-Read/Write Queue Bypass[/B]
  Specify the number of times that the oldest operation in the DCI read/Write
queue may be bypassed .                
[B]
-Queue Bypass Max[/B]
  Specify the maximum of times that the oldest memory-access request in
the DRAM controller queue may be bypassed .               
[B]
-DRAM Idle timer. [/B]
Determine the number of clocks the DRAM Controller will remain in the idle
state before it begins precharging all pages.
 
Perfect, thank you! Now I just gotta a little deciphering to do.

Right now I have the VCore at 1.39 and with LLC enabled its running about 1.4, 1.41. I think unless I can figure out something to do with the RAM or upgrade, I'm stuck. I'm trying to achieve something I can run at 24/7 and I primarily just game so 4.4 is way overkill I know. But the fact I can't seem to get it stable at that has sorta forced it to be the goal :bang head Really I'm not sure what would be optimal for 24/7 use, lowering the RAM timing and pushing the CPU as far as possible or finding a healthy medium? I can easily sit stable at 4.2 and 1600, with the voltages well in spec, but pushing it any further it just seems to go over the edge. It's frusterating to me though because I have another i7 next to it in a EVGA classified e760 with a noctua nh-d14 running beautifully at that same ratio and you'd think the setup with a d5 and two rads could demand more. I've tried switching the two cpus between setups as well and they seem to get the same results. I also tried lowering the CPU multiplier and I can get the baseclock up to 210, but at 211, craziness starts to happen. I've raised the PCIE frequency up to about 107, but I have an SSD and I've heard its not wise to do due to data corruption? I'm also not sure whats the best approach to stabilizing the PCIE as you raise it?

Anyway what is considered the best approach for a gaming rig for 24/7 use, focus mainly on RAM timings with a decent CPU OC, a high base clock with a low multiplier, or a high multiplier with a decent base clock? I have the IOH vcore and IOH PCIE running at 1.3 and 1.61 respectively for two 580s in SLI at 1.25 940 on the cores and I'm not sure if I can take those voltages much further, if that is how you stabilize an increased frequency on the PCIE?

I apologize that this has gotten a little more broad than simply a question entirely centered on RAM.

Thanks again, its fantastic to find a place to ask these questions rather than finding half answers randomly digging around the net.
 
:welcome: to OCForums!

I'm assuming you've tried plenty of vcore settings too. Have you tried reducing the RAM multiplier to as low as possible while OCing the CPU? That will eliminate the RAM from the instability equation. You can try increasing the PCIe Frequency, it's usually needed for high bclk.

Timing descriptions are below, wrapped in [code][/code] to reduce its massive size...lol.

Code:
[B]-Cas# Latency (tCL).[/B]
Number of clocks that elapses between the memory controller telling
  the memory module to access a particular column in the current row,
and the data from that column being read from the module's output pins.
[B]
-RAS# to CAS# Delay (tRCD).[/B]
Controls the number of clocks inserted between a row activate command
and a read or write command to that row. Last Intel chipset (965 and P35)
allow to change RAS# to CAS# Read Delay and RAS# to CAS# Write Delay separately                  
[B]
-RAS# Precharge (tRP). [/B]
Controls the number of clocks that are inserted between a row precharge
command and an activate command to the same rank.                  
[B]
-Activate to Precharge delay (tRAS). [/B]
Number of clocks taken between a bank active command and issuing the
  precharge command. Usually, tRAS=tCL + tRCD + 2.                  
[B]
-Row Cycle Time (tRC). [/B]
Determines the minimum number of clock cycles a memory row takes to
complete a full cycle, from row activation up to the precharging of
the active row. For optimal performance, use the lowest value you can,
according to the tRC = tRAS + tRP formula. For example:
if your memory module's tRAS is 7 clock cycles and its tRP is 4 clock cycles,
then the row cycle time or tRC should be 11 clock cycles.                  
[B]
-Refresh to Activate Delay / Refresh Cycle Time (tRFC). [/B]
Determines the number of clock measured from a Refresh command (REF)
until the first Activate command (ACT) to the same rank                  
[B]
-Refresh Mode Select (RMS) / Refresh Period (tREF). [/B]
Determines at what rate refreshes will be executed. Contrary to other timings,
higher value is better for performance.                   
[B]
-Command Rate / Command per Clock (1T/2T). [/B]
Delay between when a memory chip is selected and when the first active
command can be issued. The factors that determine whether a memory
subsystem can tolerate a 1T command rate are many, including the number
of memory banks, the number of DIMMs present, and the quality of the DIMMs.               
[B]
-Performance Level / Read Delay (tRD).[/B]
tRD is the number of memory clocks from DRAM Chip Select# assert
to Host Data Ready# assertion on the FSB.
  Hight influence on performance and stability.                  
[B]
-Write to Precharge Delay / Write Recovery Time (tWR). [/B]
-Write Recovery time is an internal dram timing, values are usually 3 to 10.
It specifies the amount of delay (in clock cycles) that must elapse after the
completion of a valid write operation, before an active bank can be precharged.
  -Write to Precharge is a command delay, and is calculed as:
Write to Precharge = tCL - 1 +BL/2 + tWR.
BL(Burst Length) practically always 8.                   
[B]
-Write to Read command Delay / Write to Read Delay (tWTR). [/B]
-Write to Read delay is an internal dram timing, values are usually 2 to 8.
Specifie the number of clock between the last valid write operation and the next
read command to the same internal bank
  -Write to Read command is a command delay, and is calculed as:
Write to Read = tCL - 1 +BL/2 + tWTR.
BL(Burst Length) practically always 8.                  
[B]
-Activate to Activate delay (tRRD). [/B]
Number of clocks between two row activate in different banks of the same rank.                  
[B]
-Read to Precharge delay (tRTP). [/B]
Number of clocks that are inserted between a read command to a row
pre-charge command to the same rank.                  
[B]
-Read to Write delay (tRTW). [/B]
Number of clocks that are inserted between a read command to a write
  command to the same rank.                   
[B]
-Round Trip Latency. [/B]
Number of Uncore clocks that are inserted for Read data after
  a Read Cas# is send to a DIMM.                   
[B]
-Four Activate Window (tFAW). [/B]
Specifies the time window in wich four activates are allowed the same rank.                   
[B]
-Precharge to Precharge delay (tPTP). [/B]
Number of clocks that are inserted between two Precharge command in
  different banks of the same rank.                  
[B]
-Write-Read Command Spacing (tWR-RD). [/B]
This field determines the number of turn-around clocks on the data bus needs
to be inserted between write command and a subsequent read command on Different Rank.                
[B]
-Read-Write Command Spacing (tRD-WR). [/B]
This field determines the number of turn-around clocks on the data bus needs
  to be inserted between read command and a subsequent write command on Different Rank.                
[B]
-Write-Write Command Spacing (tWR-WR).[/B]
  This field controls the turnaround time on the DQ bus for WR-WR sequence to
different ranks in one channel.
[B]
-Force Auto Precharge.[/B]
  When enabled, force auto Precharging with every read or write command.
This may be preferred in situation where powers savings is favored over performance.
[B]
-Maximum Asynchronous Latency.[/B]
  Specify the maximum round trip latency in the system from the processeur to
the DRAM devices and back.
[B]
-Maximum Read Latency.[/B]
  Specify the maximum round trip latency in the system from the processeur to
the DRAM devices and back. This time is specified in NorthBridge clock and
includes the asynchronous and synchronous latencies.                
[B]
-Read/Write Queue Bypass[/B]
  Specify the number of times that the oldest operation in the DCI read/Write
queue may be bypassed .                
[B]
-Queue Bypass Max[/B]
  Specify the maximum of times that the oldest memory-access request in
the DRAM controller queue may be bypassed .               
[B]
-DRAM Idle timer. [/B]
Determine the number of clocks the DRAM Controller will remain in the idle
state before it begins precharging all pages.

Where were you yesterday before I wasted all my time googling this stuff?

By the way, here is the source of that info if others are wondering: http://www.tweakers.fr/timings.html
 
Perfect, thank you! Now I just gotta a little deciphering to do.

Right now I have the VCore at 1.39 and with LLC enabled its running about 1.4, 1.41. I think unless I can figure out something to do with the RAM or upgrade, I'm stuck. I'm trying to achieve something I can run at 24/7 and I primarily just game so 4.4 is way overkill I know. But the fact I can't seem to get it stable at that has sorta forced it to be the goal :bang head

More vcore is always an option if temps are good, which they should be since you are water cooling.

Really I'm not sure what would be optimal for 24/7 use, lowering the RAM timing and pushing the CPU as far as possible or finding a healthy medium? I can easily sit stable at 4.2 and 1600, with the voltages well in spec, but pushing it any further it just seems to go over the edge.

What you should do is run the RAM at ~12XXMHz with the 6 multiplier while you work on bclk, just to see if you can get a higher bclk. If you still can't get a higher bclk, then it's not your RAM.

It's frusterating to me though because I have another i7 next to it in a EVGA classified e760 with a noctua nh-d14 running beautifully at that same ratio and you'd think the setup with a d5 and two rads could demand more. I've tried switching the two cpus between setups as well and they seem to get the same results.

The E760 is known for an easier high bclk than the R3E. Since you said that you switched the CPUs and got the same results on both shows that it's not the CPU.

I also tried lowering the CPU multiplier and I can get the baseclock up to 210, but at 211, craziness starts to happen. I've raised the PCIE frequency up to about 107, but I have an SSD and I've heard its not wise to do due to data corruption? I'm also not sure whats the best approach to stabilizing the PCIE as you raise it?

Between 100-110 should be plenty for a 210 bclk. I haven't had any data corruption with a high PCIe and SATA drives, but I guess it's a possibility.

What's your QPI and Uncore at when going that high on bclk?

Anyway what is considered the best approach for a gaming rig for 24/7 use, focus mainly on RAM timings with a decent CPU OC, a high base clock with a low multiplier, or a high multiplier with a decent base clock?

For gaming and 24/7 use, changes RAM speed and timings will not be noticeable. For that matter, I doubt going from 4.2GHz to 4.4GHz will be noticeable either. As you said, it's not needed anyway.

Where were you yesterday before I wasted all my time googling this stuff?

By the way, here is the source of that info if others are wondering: http://www.tweakers.fr/timings.html

Thanks. I couldn't remember where I had copied that from, I've had it in a .txt file forever it seems.
 
Right now my QPI is at 3753.3 and uncore at 3336. QPI voltage is 1.38 with LLC enabled, so by meter reading its around 1.39 or so. That being said, I may have been wrong all together and its the CPU causing the weird BSODs. I disabled HT and it not only stabilized but my Linpack scores got higher, by 6-7 GFlops? I was trying to leave HT enabled since on some programs it helps, but I've read it can hinder gaming performance? The question then is which is better, a quad no ht and a high oc, or a quad w/ ht and a decent oc?

You don't by chance know what healthy scores for linpack would be? On both setups I tend to be around high 50s, tho now with HT off I'm at 63 gflops. This seems low tho as I've seen some with similar frequencies getting scores around 70 or 80? The ram timings it appears anyway seem to make the results more consistent with one another, which is why tightening them became such an issue to begin with.

Thanks again for the responses.
 
It depends on what you do with it. For games it will be better to have it off and have the higer OC. For everything else it will depend on how much overclock you ahve to give up to get it stable. Encoding benefits a fair amount from HT. I would say the same for general productivity applications, if you do alot of multitasking you could benefit from HT, but not if you have to give up too much OC, but really for MS word and browsing the internet you won't notice a difference, I'm talking more about photoshop and such.
 
Back