CAS latency: why CL16 isn't always faster than CL18

Lower CAS latency is not always better, because CL counts clock cycles and a cycle gets shorter as the data rate rises, so two CL numbers mean nothing until you convert them to nanoseconds. Multiply the CL by 2000 and divide by the data rate: DDR4-3200 CL16 and DDR4-3600 CL18 are both 10.00 ns, and DDR5-6000 CL30 is 10.00 ns against 12.00 ns for DDR5-6000 CL36. At equal nanoseconds the DDR4-3600 kit is the better part, because it moves 12.5 percent more data on a board that runs both at the same controller ratio. And a 2 ns gap is a small slice of the 60 to 90 ns a processor waits for memory, so speed grade, capacity and rank count come before CL, and on a server CL can be ignored entirely.

Convert CL to nanoseconds before you compare

Every DRAM timing published as a bare number is a count of clock cycles. Every one of them converts to time the same way:

tCK (ns)  = 2000 ÷ data rate in MT/s
time (ns) = cycles × tCK
          = cycles × 2000 ÷ data rate

The division by two turns the transfer rate back into the clock that produced it. DDR moves data on both edges, so a 3200 MT/s part runs a 1600 MHz bus clock and a tCK of 0.625 ns; the speed guide covers MHz against MT/s. The formula works for every timing, tRCD, tRP, tRAS, tRFC or tFAW, and nanoseconds are the only unit in which timings from different speed grades can be compared. Where a figure in this guide is a JEDEC requirement, the standard is named (JESD79-4 for DDR4, JESD79-5 for DDR5); where it is worked out here, the arithmetic is written out so it can be checked.

Worked through for six DDR4 kits:

The first two rows are the headline: identical latency, different bandwidth, and the kit with the worse-looking number is the better part. The last two rows are what second-hand server memory usually is, and a CL19 module and a CL15 module can be within a fifth of a nanosecond of each other.

The same arithmetic on DDR5

DDR5 kits carry CL40, CL46, even CL52, numbers that would be catastrophic on DDR4. Convert them and they are ordinary:

The first four rows are JEDEC grades, which is what a DDR5 module runs with no profile switched on; the bins section explains the letters. The rest are enthusiast kits running an XMP or EXPO profile. DDR5-6400 CL32 matches DDR4-3200 CL16 exactly at 10.00 ns while moving twice the data, and DDR5-6000 CL30 reaches the same 10.00 ns at a slightly lower data rate. A DDR5-5600 or DDR5-4800 module with no CL in the listing is a JEDEC part: near 14 ns if it is an AN bin, 16 ns or worse otherwise.

Is DDR5-6000 CL30 worth paying more for than CL36?

Usually only on a gaming desktop, and only when the price gap is small. The two kits run the same data rate, so they move the same data. The whole difference is latency:

DDR5-6000, tCK = 0.3333 ns
  CL36   36 × 0.3333 = 12.00 ns
  CL30   30 × 0.3333 = 10.00 ns
  difference         =  2.00 ns, one sixth of the CL36 figure

Two nanoseconds shrinks once it sits inside the whole path a load travels. The idle load-to-use figure on current desktop platforms is quoted in the 60 to 90 ns band; on the 70 ns stand-in used in the latency accounting, 2 ns is under 3 percent, and it applies only to loads that miss every cache and that no prefetcher saw coming. AMD’s memory compatibility list carries a separate “EXPO Technology: Featuring Ultra Low Latency” certification, benchmarked as of March 2026 at DDR5-6000 across CL28, CL30 and CL36 on a Ryzen 7 9700X with an RTX 5090 over 35 games. Converted, those are 9.33, 10.00 and 12.00 ns: CL36 is inside AMD’s own low-latency tier, and the whole tier spans 2.67 nanoseconds.

Three conditions decide whether the 2 ns shows up at all. The profile has to be applied, because both kits are usually JEDEC 4800 or 5600 B parts underneath. The board has to train it at your population, which is harder with four modules than two. And the data rate has to sit on the right side of the memory controller ratio, which on current AMD platforms sits near DDR5-6000 (the platform section). Compare what the gap costs on the DDR5-6000 listings, and how DDR5 prices are moving on Trends, before paying for it. If the CL30 premium would buy the next capacity step, the capacity is the better purchase.

What CAS latency is worth, by workload

The answer varies by an order of magnitude, and the axis is not fast against slow. It is latency-bound against bandwidth-bound against parallelism-bound.

HPC and AI are the bandwidth-bound case, and compilation is not. Phoronix’s comparison of DDR5-4800 against DDR5-6000 on a 128-core EPYC 9755 with twelve memory channels concluded that “for HPC, AI, and other memory bandwidth intensive workloads, it definitely makes sense getting DDR5-6000/DDR5-6400”, while “in some cases like CI/CD build boxes and other workloads favoring high core counts but not so memory bandwidth intensive, sticking to DDR5-4800 can make sense”. The same modules were retimed in firmware, so both grades sat at roughly the JEDEC 16 ns floor and the entire difference was bandwidth.

Virtualization is the row-conflict case. Forty guests generate forty uncorrelated address streams into the same banks, so the access mix shifts toward the slowest of the three access cases, and a pair of dual-rank modules will usually beat a pair of single-rank ones with better timings (the bank count shows why). Anything running in a virtual machine or a container inherits the host’s memory configuration, including whether the host enabled a profile at all.

What to do on a listing page

1. Convert before you compare, and never compare CL numbers across speed grades. A DDR4-3200 module at CL16 and a DDR4-3600 module at CL18 are the same 10.00 ns, so whichever is cheaper per gigabyte is the better buy, and the faster one throws in 12.5 percent more bandwidth if the board will train it. DDR5-6400 CL32 and DDR5-6000 CL30 are also both 10.00 ns, but on the AMD platforms whose controller ratio boundary sits near DDR5-6000, 6400 usually crosses it, so buy the grade below it (the platform section).
2. Treat a listing with no CL as its JEDEC bin, not as the kit you hoped for. Most second-hand server pulls genuinely are JEDEC parts. Where this site cannot source a figure from a listing, it records the field as not stated rather than inferring one (methodology), because a CAS latency guessed from a part number prefix would put the wrong module at the top of a sorted table. Start from the generation you need: DDR4, DDR5, DDR3, DDR2 or DDR.
3. Buy rank count and capacity before you buy timings. A dual-rank module with ordinary timings beats a single-rank one with good ones on anything with real concurrency behind it.
4. On a server, sort by capacity per slot and speed grade and ignore CL entirely. The register costs its clock whatever you buy, parity costs four to six more if the firmware wants them, and the refresh tax on dense modules is larger than every timing decision combined. The registered DDR4 listings and the server-grade DDR3 behind them are priced on capacity.
5. Check the part number against the manufacturer rather than the title. The part number index resolves a module to what it actually is, and a part number is the only field a seller cannot round in their own favor.
6. Check the module against the machine before the timings matter at all. Memory by server and vendor pages such as Dell and HPE carry the populated-slot speed derating that decides whether the grade you bought is the grade you get.
7. Read Configured Memory Speed on the installed machine. If dmidecode -t 17 shows it below Speed, a profile is not being applied or the population has derated the channel, and that gap is worth more than every timing in this guide put together.
8. Compare against the whole catalog before deciding a grade is cheap. The full price table ranks every generation on price per gigabyte and Trends shows how those prices move. The second-hand market prices capacity and ignores timings almost completely.

Why CL rises with the speed grade: the rounding

A DRAM die is designed to a time, not to a count. Its internal delays are physical, but the die can only be told about them in whole clock cycles. So the count set in the mode register has to be rounded up to the next whole cycle that is at least as long as the physical minimum:

CL = ceiling( tAA(min) ÷ tCK )

Everything left over between CL × tCK and tAA(min) is a real delay the machine waits through and the silicon did not need. Run that on one module’s published floor of 13.750 ns at each of the standard DDR4 grades:

That table is a derivation from a real published SPD value, shown below. Two things fall out of it. The same die gets slower in nanoseconds as you clock it faster, up to the point where the rounding lands on a whole number again. And 13.750 ns is exactly 22 cycles at DDR4-3200, which is why JEDEC’s DDR4-3200AA speed bin is 22-22-22 and its tighter sibling bin, at 20-20-20, corresponds to a 12.500 ns floor. JEDEC pins the nanoseconds and lets the cycle count follow the clock. The letters on a speed bin are a nanosecond floor wearing a cycle count.

It also disposes of the folklore that dropping CL by one is always worth trying. At DDR4-3200 it is worth 0.625 ns and at DDR4-1600, the top of the table, 1.25 ns, and whether the die accepts it depends on how far the rounded count sits above the physical floor. On a grade where the rounding wasted nothing, there is nothing to reclaim.

One module, five CAS latencies

Every DIMM carries a small serial presence detect (SPD) EEPROM holding the minimum times the silicon needs, in nanoseconds, and the CAS latencies the module supports at each standard speed. On Linux, decode-dimms reads it. What follows is the shape of its output, carried through this guide with one module, not a capture from a particular machine:

$ sudo decode-dimms

---=== Timings at Standard Speeds ===---
AA-RCD-RP-RAS (cycles) as DDR4-2666              19-19-19-43
AA-RCD-RP-RAS (cycles) as DDR4-2400              17-17-17-39
AA-RCD-RP-RAS (cycles) as DDR4-2133              15-15-15-35
AA-RCD-RP-RAS (cycles) as DDR4-1866              13-13-13-30
AA-RCD-RP-RAS (cycles) as DDR4-1600              11-11-11-26

---=== Manufacturer Data ===---
Module Manufacturer                              Samsung
Part Number                                      M471A2K43CB1-CTD

One physical module, a 16 GB DDR4-2666 SODIMM, advertising CL19, CL17, CL15, CL13 and CL11. The CL column varies by 73 percent; converted, the latency varies by 3.6 percent, because all five are the same ceiling function applied to the same floor:

---=== Timing Parameters ===---
Minimum Cycle Time (tCKmin)                      0.750 ns
Minimum CAS Latency Time (tAA)                   13.750 ns
Minimum RAS to CAS Delay (tRCD)                  13.750 ns
Minimum Row Precharge Delay (tRP)                13.750 ns
Minimum Active to Precharge Delay (tRAS)         32.000 ns
Minimum Active to Auto-Refresh Delay (tRC)       45.750 ns

tRC is tRAS plus tRP by definition: 32.000 plus 13.750 is 45.750 exactly. JESD21-C, the SPD standard, stores DDR4 timings in 125-picosecond units plus a signed fine correction, which is why decode-dimms prints DDR4-2133’s tCK as 0.938 rather than 0.9375. The module tells you its physical floors, not its marketing numbers. A listing’s CL is a claim about which advertised count the seller chose to quote, or, for an enthusiast kit, about a profile that has to be switched on.

The DDR5 bins, and the rule that makes CL40 out of a 39

The JEDEC B bins are 40-39-39 at 4800, 46-45-45 at 5600 and 52-52-52 at 6400, and all three land within half a nanosecond of each other: the pinned-nanoseconds rule at work. Micron’s DDR5 datasheets give the same tAA, tRCD and tRP minimum of 16.000 ns and a tRC of 48.000 ns for the 4800B, 5200B, 5600B and 6400B bins alike.

Each data rate has four bins at two nanosecond floors. Micron’s DDR5-5600 table runs AN at 40-40-40, B at 46-45-45, BN at 46-46-46 and C at 50-49-49, with the AN grade held to a tAA of 14.285 ns and the other three to 16.000 ns or worse. Across every rate from 4800 to 6800 the AN column sits near 14 ns and the B column at exactly 16.000.

Now look at 4800B: 40-39-39, two identical nanosecond floors producing two different cycle counts. DDR5 encodes CAS latency in mode register 0 in even steps only (a JESD79-5 rule, not a property of the die), so the rounded count for tAA goes up to the next even number while tRCD and tRP take the odd one:

DDR5-4800, tCK = 0.41667 ns

tRCD floor 16.000 → 16.000 ÷ 0.41667 = 38.4 → 39      odd count allowed
tAA  floor 16.000 → 16.000 ÷ 0.41667 = 38.4 → 39 → 40 rounded again to even

wasted by the even-step rule = (40 − 39) × 0.41667 = 0.42 ns

The DDR5 module you actually get is slower in nanoseconds than the DDR4 one it replaced. B-grade parts are what ships, and 16 ns against the 13.75 ns of the DDR4-3200 bin is why early DDR5 disappointed people who had read the bandwidth figures. A DDR5 kit quoting much better than about 14 ns is running an overclocking profile: DDR5-6400 CL32 is 10.00 ns, but the nearest JEDEC bin at that rate is 6400AN at CL46. The bin letter sits in the module’s PC5 designator the way DDR4’s sat in PC4-3200AA, and if a DDR5 listing gives neither CL nor timings, the module is a JEDEC part.

Twenty years of flat latency

Take the standard JEDEC bin at the top of each generation and convert it:

Bandwidth went up by a factor of sixteen. First-word latency did not move. The CL number went up by a factor of seventeen and described none of it. The last two rows are the same data rate at two JEDEC grades: the B bin, which most DDR5-6400 modules carry, is 2.5 nanoseconds worse than a DDR3-1600 module from 2009, and the AN bin is 0.63 ns worse, close enough to call level. A kit that advertises 6400 has not told you which of the two you are buying unless it prints the timings.

The reason is tRC, the time a bank takes to open a row, read it and close it again, which is a property of the cell, the bitline capacitance and the sense amplifier. JEDEC’s tRAS plus tRP for DDR-400 is 40 + 15 = 55 ns and for DDR2-800 is 45 + 12.5 = 57.5 ns; DDR3-1600 is 35 + 13.75 = 48.75 ns and DDR4-3200AA is 32 + 13.75 = 45.75 ns. A fifth off the row cycle in twenty years, against a factor of sixteen on bandwidth. The data rate is a property of the I/O circuitry at the edge of the die, which scales with the process. Everything DDR has done since DDR2 is an attempt to extract more bandwidth from an array whose access time is fixed: prefetch depth, bank groups, subchannels and the thirty-two-bank organization are all more concurrency over the same slow array.

So a DDR3 module is not meaningfully slower to respond than a DDR4 one; it is narrower. DDR2 and DDR parts are within two nanoseconds of a current DDR5 module on the number people argue about. The choice between the two current generations is DDR4 vs DDR5.

What the four primary timings gate inside a bank

A listing that gives timings at all usually gives four, in a fixed order: 19-19-19-43 in the dump above. They gate four different physical events, and only the first is CL. A DRAM bank is a grid of cells. A row, or page, is one line of cells sharing a wordline; a column selects which part of the opened row goes out; and a strip of sense amplifiers holds the row while it is open. For an 8 Gbit DDR4 device organized x8, a row is 1 KB per device, and eight devices make one rank’s 64-bit path, so one activate command opens 8 KB across the rank even if the processor asked for 64 bytes of it.

• tRCD is the time from the activate command until the sense amplifiers hold a value stable enough to read. It is a physical settling time that scales with process and array geometry and essentially not at all with the speed grade.
• CL, which JEDEC calls tAA, is the delay from the read command to the first word on the bus, with the row already open. It is the only pure transport delay of the four, and the only one an enthusiast kit reliably improves, which is a large part of why the marketing settled on it.
• tRAS is the minimum time from activate to the earliest permitted precharge. Reading a cell destroys its charge, and tRAS lets the sense amplifier write it back. On the module above it is 32.000 ns against 13.750 for each of the other three: the number nobody quotes is more than twice the one everybody does.
• tRP is how long precharge takes, returning the bitlines to their reference voltage so the next activate starts clean. tRP and tRCD land on the same floor on most parts, which is why the second and third numbers of a timing string are so often equal.

The three cases, priced

What the four combine into depends on what is already open in the bank:

CL is the best case, and buying on CL alone optimizes the case you were already going to win. The spread across those three rows is three to one; the spread between a good CL and a bad one at the same speed grade is more like one and a tenth to one. A kit with a tight CL and a loose tRCD is worse than its headline suggests, and the headline is usually the only number a seller types.

The same three cases on a current DDR5 enthusiast kit: G.Skill’s Trident Z5 F5-6000U3636E16GX2-TZ5K is DDR5-6000 at 36-36-36-76, a tCK of 0.3333 ns:

row hit        36 x 0.3333             = 12.00 ns   against 14.25 ns   -15.8%
row miss      (36 + 36) x 0.3333       = 24.00 ns   against 28.50 ns   -15.8%
row conflict  (36 + 36 + 36) x 0.3333  = 36.00 ns   against 42.75 ns   -15.8%

The same 16 percent in all three cases. Both parts run their three primary timings in equal proportion, 19-19-19 against 36-36-36, so every case scales by the tCK ratio alone. Where the timings are not in proportion the cases come apart: the generation comparison runs DDR4-3200 CL16-18-18 against DDR5-6400 CL32-39-39 and finds the open-row case identical at 10.00 ns while the row conflict gets about six percent worse, 32.50 ns against 34.38. The same check applies to a DDR5-6000 CL30 kit: its CL is one of three numbers, so read its tRCD and tRP before assuming the 2 ns gain carries through a row miss or a conflict.

There is a fourth case nobody puts on a label, and on a busy machine it is the common one: the request waits in the memory controller’s queue behind others for the same bank. Little’s law is why that grows under load.

Bursts, bank groups and how many banks a bus needs

CL measures the arrival of the first word, and a read returns a burst. DDR4’s 8n prefetch streams eight words over the 64-bit channel; DDR5’s 16n prefetch streams sixteen over a 32-bit subchannel. Both are 64 bytes, exactly one x86 cache line:

Critical word first means the controller starts the burst at the word the load wanted, so the dependent instruction issues as soon as that word lands, which is why CL and not CL plus the burst is the latency number. Moving the data takes between about 1.8 and 3.3 nanoseconds on every generation in that table, and everything else is waiting for the array. The data bus is idle for most of a single request’s life, which is why bandwidth and latency are close to independent and why memory systems are designed around overlapping requests.

Bank groups: tCCD_S and tCCD_L

By DDR3-1600 the column path inside the die could not accept a new read every four clocks. DDR4’s answer was bank groups, each with its own column decode and prefetch resources: four groups of four banks on a x8 device, sixteen banks, and two groups of four on a x16 device. Reads to different groups go back to back at tCCD_S, four clocks, equal to the burst. Reads to the same group wait tCCD_L, which JESD79-4 pins in nanoseconds, five clocks at the slower grades and six or more at the faster ones. At six clocks on DDR4-3200:

same bank group   6 clocks per 64-byte burst  →  64 B ÷ (6 × 0.625 ns) = 17.07 GB/s
cross bank group  4 clocks per 64-byte burst  →  64 B ÷ (4 × 0.625 ns) = 25.60 GB/s

loss from failing to interleave across bank groups = 33 percent

A third of the channel’s peak bandwidth, decided by a parameter that appears in no listing and no timing string, and set by the controller’s address mapping. A DDR5 x4 or x8 device carries eight bank groups of four banks, thirty-two banks in total. Its tCCD_L has a floor of roughly five nanoseconds and of eight clocks, so at the higher grades it runs well above the burst, and the eight groups give the controller far more places to send the next read.

How many banks a bus of a given speed needs

Under pure row-miss traffic a bank is busy for a full row cycle, tRC, per burst, while the data bus is busy for one burst duration:

banks needed = tRC ÷ burst duration

The tRC values are the published floors: 45.75 ns from the SPD dump above and 48.00 ns for the DDR5 JEDEC A and B grades. A single rank of DDR4-3200 does not have enough banks to saturate its own data bus under row-miss traffic. It needs 18.3 and has 16, which is the real reason a pair of dual-rank modules beats a pair of single-rank ones on a server workload even when the single-rank pair has better timings: the second rank is sixteen more banks. Rank count is covered in ranks and 3DS modules, and it is the specification most worth checking on a second-hand DDR4 server module.

DDR5 has thirty-two banks because the organization had to be sized for the top of its data rate: at DDR5-8800 the requirement is 26.4. Each DDR5 DIMM also splits into two independent 32-bit subchannels with their own command bus and scheduler, so the module presents sixty-four banks and two schedulers where DDR4 presented sixteen and one. That is worth more on a mixed workload than any CAS latency on the market, and it is why the first DDR5 parts beat DDR4 on throughput while losing to it on idle latency.

tFAW and the address mapping: the limits on scattered access

Raising a wordline and sensing a row are current events, and too many too close together brown out the die’s internal rails. JEDEC caps the rate:

tFAW is the one that binds. JESD79-4 sets it per page size and speed grade, in nanoseconds because the current draw is physical. The worked example uses 21 ns, the right order for a 1 KB page part at DDR4-3200:

four activates per 21 ns  →  one row opened every 5.25 ns

Under pure row-miss traffic each activate yields exactly one 64-byte burst
before the row is closed again, so:

sustained rate = 64 B ÷ 5.25 ns = 12.19 GB/s
channel peak   = 3200 MT/s × 8 B = 25.60 GB/s

ratio = 12.19 ÷ 25.60 = 47.6 percent

A DDR4-3200 channel under fully scattered access cannot exceed about half its peak bandwidth, no matter how many banks are idle and no matter what CL the kit carries. The figure is derived rather than measured, but its order is why random-access memory benchmarks land where they do. With tRRD_S at four clocks, four cross-group activates could go out in ten nanoseconds; tFAW stretches that to twenty-one. The power budget is the limit, not the command bus and not the array.

How often each of the three access cases happens is decided by the controller’s address mapping, which no listing describes. Put the column bits low and consecutive cache lines share an open row; put the channel and bank bits low and they scatter across the memory system. Real controllers choose to scatter, because the cache already took the locality worth having, and they hash the bank selection so a power-of-two stride does not send every access to the same bank. That is why a strided loop’s speed can change sharply with a small change in the stride. They also switch per bank between leaving a row open and closing it after the burst with a read-with-auto-precharge, gated by tRTP, the read-to-precharge delay. Your row hit rate is a property of your access pattern and the controller’s policy, and nothing about the module changes it.

Refresh: tREFI, tRFC and the tax that grows with density

A DRAM cell is a capacitor with a leaky access transistor. Left alone it loses its charge, so every row in the device must be read out and written back periodically. That is refresh, and it is the only timing in this guide that gets worse as modules get bigger.

JESD79-4 requires every row to be refreshed within a 64 ms retention window, and the device is organized so that 8192 refresh commands cover the whole array:

tREFI = 64 ms ÷ 8192 = 7.8125 µs

So the controller issues a refresh command on average every 7.8125 microseconds at normal temperature. tRFC is how long the rank is unavailable while it happens. During an all-bank refresh the entire rank is busy; no bank in it can accept a read.

The tax, worked out

JESD79-4 sets tRFC1 by device density. The published values:

tRFC2 and tRFC4 are the fine granularity refresh modes: refresh half or a quarter of the usual amount of the array in one command, at a proportionally shorter stall but a proportionally shorter interval, so the total time cost goes up slightly while the worst-case single stall goes down. That trade exists for latency-sensitive systems that cannot tolerate a 550 ns hole.

Divide the stall by the interval and you get the fraction of time the rank is unavailable. This arithmetic is done here, from the JEDEC figures above:

A hot 16 Gbit module spends one clock in seven refreshing itself. That is not a tuning parameter and it is not on any label. It is the largest single throughput term in this guide, it is invisible to every listing, and it is why memory cooling on a densely populated server is a performance question rather than a longevity one. The temperature sensor on the module is what tells the controller to switch to the doubled rate, which is one reason DDR5 put the sensor in the specification rather than leaving it optional.

Every density step costs more than the last. Going from 8 Gbit to 16 Gbit dies costs 2.5 points of availability at normal temperature and 5 points when hot, and that cost lands on exactly the people who want the biggest modules.

Stacked 3DS modules refresh per die

A 64 GB or 128 GB DDR4 registered module is not built from enormous dies. It is built from stacks of ordinary dies connected by through-silicon vias, which JEDEC calls 3DS. Take a 64 GB DDR4 RDIMM made from eighteen x4 packages, each a four-high stack of 8 Gbit dies:

16 data packages × 4 dies × 8 Gbit = 512 Gbit = 64 GB
(the other two packages carry the ECC width)

The module label reads 4Rx4, because the stack presents as four logical ranks. The refresh parameter that applies is the one for an 8 Gbit die, not the one for a 64 GB module, because each die in the stack is refreshed as its own logical rank. A 64 GB module built this way pays the 8 Gbit refresh tax of 4.5 percent, not the 16 Gbit tax of 7.0 percent. JEDEC’s 3DS addendum also defines tRFC_slr, the refresh cycle time when the refresh targets the same logical rank, and tRFC_dlr, the much shorter one when it targets a different logical rank in the same stack, so refreshes to different layers can overlap. A taller stack does not multiply the refresh stall, because it is several small devices sharing a package. That is worth knowing when comparing two 64 GB DDR4 modules with the same capacity and different rank counts on the label; how ranks and stacks work is ranks and 3DS modules.

DDR5 changed the refresh model

DDR5 kept the same idea and added an escape. Alongside the all-bank refresh it defines a same-bank refresh, where the command refreshes one bank in each bank group rather than the whole rank, so the other banks stay available to serve reads through the stall. The per-density tRFC values and the refresh intervals are in JESD79-5’s tables. The structural change is the one to remember: DDR5 does not require the rank to go dark to refresh, and on a workload with enough bank parallelism that turns a throughput tax into a scheduling problem.

DDR5 also added on-die error correction over each internal 128-bit word. That is not module ECC and reports nothing to the operating system; ECC and non-ECC explains the difference.

Writes and bus turnaround

Writes have their own timings:

tWR exists for the same reason as tRAS: closing the row before the cells take the new charge loses the data. The expensive part is a property of the bus. A DQ bus has one set of drivers and they point one way at a time, and switching between reading and writing costs several clocks each way, every time the traffic changes direction. That is why controllers batch reads, then batch writes, and why a workload that alternates reads and writes to the same region performs much worse than either alone. None of this appears in a timing string, and all of it is larger than the difference between two CAS latencies.

Registered modules: a clock for the register, more for parity

On a registered module, the address, command and clock signals land on a registering clock driver (RCD), which samples them, holds them for one clock, and retransmits clean copies to the DRAM chips; the data lines bypass it. JESD82-31 is the DDR4 RCD definition and JESD82-511 the DDR5 one, revised since as JESD82-514 and JESD82-515. Every command therefore arrives one clock late, and the extra clock is not in the CL on the label:

DDR4-2666 RDIMM, CL19
  unbuffered equivalent   19 × 0.750           = 14.25 ns
  through the register    (19 + 1) × 0.750     = 15.00 ns

DDR5-4800 RDIMM, CL40
  unbuffered equivalent   40 × 0.41667         = 16.67 ns
  through the register    (40 + 1) × 0.41667   = 17.08 ns

The benefit is why registered memory exists: a clean, fully driven command bus lets a channel carry two or three dense dual-rank or quad-rank modules at a rated speed. The compatibility side is RDIMM, UDIMM and LRDIMM. An LRDIMM also buffers the data lines (ten data buffers per module on DDR5), which costs latency on every transfer.

Command and address parity

DDR4 added parity on the command and address bus, checked by the register. JESD79-4 covers the checking time with a parity latency, set in mode register 5 as four, five or six clocks depending on the speed grade, added to every command the module receives while parity is enabled:

DDR4-2666, parity latency of 5 clocks
  cost per command          5 × 0.750 = 3.75 ns

DDR4-2666, CL18 against CL19
  difference                1 × 0.750 = 0.75 ns

ratio                       3.75 ÷ 0.75 = 5

Enabling command and address parity on a registered module costs five times what the entire CL18-versus-CL19 argument is worth, on every command, and no tool a normal user runs will tell you whether it is on. It is a reasonable thing to have on, because a corrupted address is a silent write to the wrong place and the alert turns that into a detected fault. A server’s memory latency is set by decisions of that size, and CL is not one of them.

Command rate and gear-down

A five-part timing string ends in 1T or 2T (sometimes 1N or 2N): the command rate, how many clock cycles a command is held on the address bus. 2T is the safe setting when several modules or ranks load the address lines; it costs one clock per command, 0.625 ns at DDR4-3200 and 0.333 ns at DDR5-6000, and it is the first thing a board gives up when you fill all four slots. Gear-down mode is a different DDR4 feature, set through mode register 3 and on by default on many AMD boards, that halves the rate at which the DRAM samples its command and address bus. Only the command rate appears in a timing string.

Where the latency actually goes

A program waits for a load instruction to produce a value, and the DRAM is one term in that. The load misses L1, L2 and the last-level cache, crosses the interconnect to the memory controller, queues, is scheduled against every timing above, and the data crosses back. That whole path is what a memory latency tool reports, quoted at 60 to 90 ns for an idle load to use on current desktop platforms. The arithmetic below carries 70 ns as a round stand-in for that band, not a measurement:

idle load-to-use, whole path              ≈ 70.0 ns
of which the DRAM device contributes, row hit at DDR4-3200 CL16
                                          = 10.0 ns   = 14 percent
of which the DRAM device contributes, row conflict
                                          = 30.0 ns   = 43 percent

Improving CL16 → CL14 at DDR4-3200 saves  =  1.25 ns
as a fraction of the whole path           =  1.8 percent

The two-cycle CAS latency improvement people pay a premium for moves the number the processor experiences by under two percent, and only on accesses that hit an open row. The DDR5 version is the same order: DDR5-6000 CL30 against CL36 saves 2.00 ns, under 3 percent of the same 70 ns.

Little’s law, and why one thread cannot fill a channel

Bandwidth and latency are tied by a relation that has nothing to do with memory:

bandwidth = concurrency ÷ latency

The bytes that must be in flight to sustain a bandwidth at a latency are the product of the two. On one DDR4-3200 channel:

peak bandwidth        3200 MT/s × 8 bytes  = 25.6 GB/s
latency, stand-in                          = 70 ns
bytes in flight       25.6e9 × 70e-9       = 1792 bytes
cache lines in flight 1792 ÷ 64            = 28 lines

A single core cannot keep twenty-eight line fills outstanding. Its miss-tracking structure (fill buffers, or miss status holding registers) is on the order of ten to sixteen entries depending on the microarchitecture:

one core, 16 outstanding lines, 70 ns latency
  16 × 64 bytes ÷ 70 ns = 14.6 GB/s

A single thread tops out at a little over half a channel, limited by the core rather than the memory. That is why adding channels helps a multi-threaded workload and does nothing for a single-threaded one. Cutting 70 ns to 68.75 ns raises that single-thread figure from 14.63 GB/s to 14.89 GB/s, the same 1.8 percent, because Little’s law is linear.

The prefetcher hides it, until the address depends on the data

Hardware prefetchers issue requests before the program asks, and when they work the DRAM latency is not on the critical path at all. They work on anything whose next address can be predicted, such as walking an array, a dense matrix multiply or a memory copy, and there bandwidth is what matters. They fail on the dependent load chain, where the next address is in the data of the current load: pointer chasing, hash table lookups, A[B[i]] indirect indexing, database index descent.

B-tree over 10^8 keys, fanout 100, four levels deep
  four dependent misses per lookup at 70 ns = 280 ns of stall per lookup

with CL16 → CL14 at DDR4-3200, saving 1.25 ns per access
  4 × 1.25 = 5 ns per lookup, or 1.8 percent

The same 1.8 percent: on a chain of dependent full-path misses the improvement is exactly the DRAM term’s share of the path. The way to make a dependent chain faster is to make it shorter or to make it fit in cache, not to shave cycles off the memory. Prefetchers on most implementations also stop at page boundaries, so on 4 KB pages a sequential stream retrains every 64 cache lines, a large part of why huge pages help streaming workloads.

Every term in one place, with its size

The full accounting for a read on a registered DDR4-2666 server module:

Now weight the three access cases for a mixed server workload at a 50 percent row hit rate, 20 percent idle miss and 30 percent conflict, as a derivation:

E[DRAM latency] = 0.50 × 14.25   (hit)
                + 0.20 × 28.50   (miss)
                + 0.30 × 42.75   (conflict)
                = 7.125 + 5.700 + 12.825
                = 25.65 ns

One cycle off the CAS latency lowers CL in all three cases, so the expectation falls by exactly 0.75 ns, to 24.90 ns: 2.9 percent of the DRAM term and about 1 percent of the whole path. Improve the hit rate instead, to 70 percent hits, 15 percent idle misses and 15 percent conflicts, which better address locality or a smarter page policy buys:

E[DRAM latency] = 0.70 × 14.25
                + 0.15 × 28.50
                + 0.15 × 42.75
                = 9.975 + 4.275 + 6.4125
                = 20.66 ns

Five nanoseconds, from changing nothing about the memory at all, six and a half times what the CAS latency upgrade was worth.

The platform decides: gears, profiles and kits a board will not train

The ratio between the memory controller’s clock and the DRAM’s regularly outweighs every DRAM timing. Intel calls it Gear 1, Gear 2 and Gear 4; AMD’s equivalent is the UCLK to MEMCLK ratio, 1:1 or 1:2. Crossing the boundary adds controller-side latency on every transaction. On the AMD platforms where the boundary currently sits near DDR5-6000, a DDR5-6400 kit running 1:2 commonly performs worse in latency-sensitive work than a DDR5-6000 kit running 1:1, despite being the faster and more expensive part. The vendors do not publish the penalty as a number, and the rule does not need one: find your platform’s ratio boundary, buy the fastest grade below it, and treat anything above it as a bandwidth purchase. Gear modes, memory training and XMP and EXPO profiles are covered in the speed guide.

The CL in a product listing is usually the rated timing under an XMP or EXPO profile. The SPD also carries JEDEC timings, and Intel is explicit that “Intel XMP memory modules will first boot with the default JEDEC settings”. So a “DDR5-6000 CL30” kit is a plain JEDEC kit, usually a 4800 or 5600 B grade, validated to do better and shipped with a profile saying so. If the profile is off or the board declines it, you own the JEDEC part at the price of the fast one. That fallback is silent, and four situations produce it:

• Filling all four slots. A board’s memory support list quotes a lower speed for four modules than for two, and lower again for dual-rank modules. Find the number for your exact population.
• Mixing kits. Two pairs bought separately train to the slowest timing all four share, often at 2T, and a four-module kit is not the same product as two two-module kits with the same part number.
• Buying unbuffered overclocking kits for a server. Server boards have no profile mechanism, most take RDIMMs only, so an unbuffered kit may not run at all (RDIMM, UDIMM and LRDIMM), and the RDIMMs they take ship with JEDEC SPD only, so there is no low-latency EPYC or Xeon module to hunt for (registered overclocking lines exist only for workstation sockets such as Threadripper).
• Buying past the memory controller, where the higher data rate forces the divided clock ratio and gives back more latency than the speed grade won.

For a server the consequence is liberating. Take the highest speed grade the platform trains, at the capacity and rank count you need, and stop. On JEDEC bins the nanoseconds do not get worse as the data rate goes up, so the fastest grade your processor supports is also the lowest-latency one. Check what fits first, and what your processor takes second.

Reading the timings off a machine you own

dmidecode reads SMBIOS, which is what the firmware decided. The output below is its shape, not a capture from a particular machine:

$ sudo dmidecode -t 17

Memory Device
        Size: 16 GB
        Form Factor: DIMM
        Type: DDR4
        Type Detail: Synchronous Registered (Buffered)
        Speed: 2666 MT/s
        Configured Memory Speed: 2400 MT/s
        Manufacturer: Samsung
        Part Number: M393A2K43CB2-CTD
        Rank: 2

Speed is what the module is rated for and Configured Memory Speed is what it is running at. A gap between them means a profile that was not applied, a population that derated the channel, a mixed set training down to its slowest member, or a processor that does not support the grade. It is the first thing to check on a machine whose memory feels slow. It will not show the CAS latency, because nothing in the SMBIOS memory device structure carries one. (The module in that output is a Samsung M393A2K43CB2-CTD.)

decode-dimms reads the SPD, which is what the module says about itself, once the EEPROM driver is bound: ee1004 on DDR4, spd5118 for the DDR5 SPD hub:

$ sudo modprobe ee1004      # DDR4
$ sudo modprobe spd5118     # DDR5
$ sudo decode-dimms

It prints the physical floors and the supported CL at each standard grade, as in the rounding section, and it is the only tool of the three that reports what the silicon can do rather than what the firmware chose. The firmware’s own memory page is the third source, and on a server usually the only place that shows the command rate, the parity setting, the refresh mode and the gear ratio. On Windows, CPU-Z reads both the SPD and the applied timings.

A listing cannot tell you the sub-timings the board will apply (tRFC, tFAW, tRRD, tWR, the command rate and the gear ratio are firmware decisions made after training), or whether a used enthusiast module’s profile will be honored: an XMP 3.0 profile on a board that reads only XMP 2.0, or an EXPO profile on an Intel board, does not exist for that machine. Nor can you trust the seller’s CL, which is a transcription from a marketing page, an old listing or the wrong line of a spec sheet at least as often as from the label, and a wrong CL still produces a working module. Which label fields are load-bearing is in buying used RAM on eBay.

Compare nanoseconds, not CL numbers, and confirm the speed grade is one your board lists before the CL number matters at all. A JEDEC module that runs at its rated speed out of the box beats a faster-looking kit your machine will not train, every time, and at a lower price per gigabyte.