Questions about tRAS, (tRAS = CL + tCRD + tRP +/- X)

commandosupremo

Honorable
Nov 4, 2013
27
0
10,540
So I just got done building my new system and dialing in the processor OC (i5-4690k @ 4.5GHz, [45multiplier, 100Blck 1.14V], 42x cache ratio [1.15V]) and I started playing with the memory timings and I'm surprised at the tRAS it is achieving.

The RAM I am using is G.Skill Trident X, 2400 MHz, factory timings: 10-12-12-31, 1.65V.

URL here:

http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=G.Skill+2400+trident&N=-1&isNodeId=1

Basically right now they are running at 10-11-11-25, 2400MHz, 1.65V. Changing tCRD or tRP to 10 causes it not to post, but I've continuously lowered the tRAS and it has been stable. I always thought that tRAS had to be the sum of the first three timings +/-1 or 2, but right now it's stable at 6 less than the sum. Is this unusual? What is the theoretical minimum value for tRAS? I've read tRAS >= CL + tCRD is the minimum but I'm not sure if this is true.

Also I noticed that the tREF value (7936) is exactly 256 times the stock tRAS, is this just a coincidence?

I've been stress testing with AIDA64 mainly and also Memtest.

I know it really doesn't impact things much but I reached my CPU OC goal and started working on the RAM for the fun of it. Any answers would be much appreciated.
 
Solution


Tras is the minimum amount of time that must exist between a row being opened (the active command) and that row being closed (the precharge command). This assumes that the row is opened only for reading purposes, and no write commands are issued.

Contrary to popular belief, there's no relationship between Tras and Tcl, or Tras and Trp. However, Tras does overlap with Trcd (it is lower bounded by it) and a good value for Tras can be approximated. Read and write commands can be issued after Trcd has elapsed, but the row cannot be disconnected until Tras has elapsed. Furthermore, if writes are made to the row, Trw must be respected as well which will extend the time until the row can be closed.

Here's the relevant explanation from my soon to be published guide

Tras: Active to Precharge Delay, or minimum /RAS time. This is the minimum number of clock cycles that a row must be open before it may be precharged. When a row in the bank’s memory array is connected to the bank’s sense amplifiers (and then latched into the row buffers) the operation is destructive in nature. The data is available at the row buffer for reading after Trcd, but it is no longer available in the memory array (see 3.2.4). Precharging the bank would result in the destruction of the row data in the memory array. To prevent this, the DRAM core automatically restores the data in the memory array such that it mirrors the data in the row buffer. This operation is very similar to a write command and has similar latency effects, so Tras is approximately equal to Trcd + Twr with some slack for safety. Precharging before Tras has elapsed may result in destruction of the row data.

Trw is standard at 15ns for all DDR SDRAM designs but the sense amplifiers have to refresh every cell on the open row (as opposed to only a handful for a write command), so a few extra nanoseconds are allocated to Tras to ensure that this operation completes successfully in light of current limitations and other considerations. Overvolting on your memory is probably helping with this a bit too. So while it may be stable at 10-11-11-25 for now, it may eventually encounter a scenario where the cells aren't fully refreshed prior to disconnecting which causes a read error.

As for Trefi, yes that is just a coincidence. Trefi should be 7.8 microseconds across the board when temperatures are below 85 degrees centigrade and 3.9 microseconds when temperatures are between 85 degrees centigrade and 95 degrees centigrade.
 
Solution

commandosupremo

Honorable
Nov 4, 2013
27
0
10,540
Thanks for the detailed response. I'm not going to keep the RAM at those settings because when I run code from work, the results need to be accurate and with long runtimes, crashes need to be kept to a minimum.

I had looked online for more information on the timings beyond the advertised ones and couldn't find much info, sounds like your guide may address some of them. Be sure to send me a link to your guide once it is published. I feel like I know a great deal about the other parts of my machine, but memory timings is a big hole in my knowledge.
 


It'll be available at the top of this forum in a few days. Check back then!