The RAM latency calculator above converts a memory kit's CAS latency from clock cycles into nanoseconds, which is the only form in which two kits running at different speeds can honestly be compared. It also reports the memory clock, the length of a single cycle, the worst-case read that includes opening and closing a row, and the theoretical peak bandwidth of one channel, so that speed and latency sit side by side rather than being argued about separately.
Arb Digital publishes this because the marketing number and the useful number are not the same number. CL is printed on every box and it is a count of clock cycles, not a duration. Cycles get shorter as the clock rises, so a bigger CL on a faster kit can represent a shorter wait than a smaller CL on a slower one. The calculator does the one division that settles the argument, and shows the two kits together so the comparison is visible rather than asserted.
What This RAM Latency Calculator Does
It applies one formula: latency in nanoseconds equals CL divided by the data rate in MT/s, multiplied by two thousand. The factor of two thousand exists because DDR memory transfers data on both edges of the clock, so the advertised transfer rate is twice the actual clock frequency, and a nanosecond is one thousandth of a microsecond. Everything else on the page is derived from that same relationship.
Two kits are calculated at once. The bars compare their CAS latency directly, and the sub-line under the headline number states which kit reaches the first word of data sooner and by how much. Where the two are equal, the page says so plainly rather than manufacturing a winner, because equal latency is the common and interesting case.
The row-miss figure adds tRP and tRCD to CL. That is the sequence the memory controller has to run when the address it wants lives in a row that is not currently open: close the active row, activate the new one, then issue the column read. It is a far larger number than CL alone, and it is the latency that most real workloads actually experience. Our frequency period calculator handles the general clock-to-period conversion if you want to check the cycle time independently.
How to Use It
- Enter Kit A's data rate and CL. These are the two numbers in a listing like "DDR5-6000 CL30" or "6000 MT/s 30-38-38-96".
- Enter Kit B's data rate and CL to compare a second module against the first.
- Set tRCD and tRP from the full timing string if you have it. They are the second and third numbers.
- Choose the bus width that matches what you are measuring — a 64-bit DDR4 channel, a 32-bit DDR5 sub-channel, or a dual-channel pair.
- Read the headline in nanoseconds and compare it against the bars. Then look at the bandwidth figure, because latency alone does not decide which kit is faster in practice.
The Formula and How It Is Calculated
CAS latency is a count of memory clock cycles. To turn a count of cycles into a duration you need the length of one cycle. For DDR memory the advertised figure is a transfer rate, and because two transfers happen per clock cycle, the clock frequency is half of it. A DDR5-6000 kit therefore runs a 3,000 MHz clock, and one cycle of a 3,000 MHz clock lasts 1 ÷ 3,000,000,000 seconds, which is 0.3333 nanoseconds.
Multiply that cycle length by CL and you have the latency. Written as a single step, latency (ns) = CL × 2000 ÷ data rate (MT/s). For DDR5-6000 CL30 that is 30 × 2000 ÷ 6000 = 10.000 ns. For DDR4-3600 CL18 it is 18 × 2000 ÷ 3600 = 10.000 ns. The two kits are identical on this measure despite CL numbers that differ by a factor of nearly two, which is the single most useful thing this page can tell you. Micron's DDR5 DRAM product documentation sets out the transfer rates and internal organisation the formula depends on.
The row-miss figure uses the same cycle length applied to a longer sequence. A DRAM chip is a grid of rows and columns. Reading requires the target row to be copied into a sense-amplifier buffer, which is what tRCD pays for, and only then can a column be read, which is what CL pays for. If a different row is already sitting in that buffer it must be written back and the bit lines returned to their idle state first, and tRP is the bill for that. With the defaults, 38 + 38 + 30 = 106 cycles at 0.3333 ns each is about 35.3 ns — three and a half times the headline number.
Peak bandwidth is unrelated to latency and is calculated separately: data rate in MT/s multiplied by the bus width in bytes, divided by one thousand to give gigabytes per second. A 6,000 MT/s channel eight bytes wide has a theoretical ceiling of 48 GB/s. Our bandwidth converter and data storage converter handle the unit work if you need the same figure in other units.
Why a Lower CL Number Is Not Automatically Better
The confusion is entirely a units problem. CL is dimensionless. It counts something whose duration is set by a separate number, so comparing CL between kits with different data rates is like comparing distances measured in one case in paces and in the other in strides, without asking how long either is.
Two consequences follow. First, as the industry pushes clock rates up, CL numbers rise with them, and a generational jump that looks like a regression on the box is often flat or better in nanoseconds. DDR4-3200 CL16 and DDR5-6400 CL32 both land on exactly 10 ns. Second, within a single data rate, CL comparisons are perfectly valid, because the cycle length is the same for both. DDR5-6000 CL30 really is faster to first word than DDR5-6000 CL36, by 30 × 2000 ÷ 6000 = 10.0 ns against 12.0 ns.
Enter both kits into the tool and the bars settle it. Where the nanosecond figures tie, the faster kit is the better buy on every other axis, because it delivers the same first-word delay and then sustains more data per second afterwards.
The Four Numbers in a Timing String
A string like 30-38-38-96 is CL, tRCD, tRP and tRAS in that order, all in clock cycles. CL is the column read delay once the row is open. tRCD is row-to-column delay, the wait after activating a row before a column read is legal. tRP is row precharge, the wait after closing a row before another can be activated. tRAS is the minimum time a row must stay open once activated, and it constrains how quickly the controller can cycle through rows rather than adding directly to any single read.
The calculator uses CL for the headline and adds tRCD and tRP for the row-miss case. It does not add tRAS, because tRAS overlaps the other timings rather than following them — it is a floor on row-open time, not another queue to wait in. Treating it as additive is a common error that inflates the estimate substantially, and it is worth knowing that the four numbers are constraints on a schedule rather than four sequential stages.
There are dozens of further timings beyond the primary four, covering refresh, write recovery, bank-group switching and more. They matter for tuning, but none of them changes the arithmetic on this page, which is about converting cycles into time.
Where Memory Latency Actually Shows Up
Most memory requests never reach DRAM. A processor's cache hierarchy answers the overwhelming majority of them in a few nanoseconds or less, and a modern prefetcher pulls in data before it is asked for. The latency this page calculates is what you pay when all of that fails: a cache miss on an address the prefetcher did not predict.
That makes the practical impact wildly workload-dependent. Streaming through a large array in order is a bandwidth problem, and latency barely registers because the prefetcher hides it. Chasing pointers through a linked structure, walking a hash table, or traversing a graph produces unpredictable accesses that the prefetcher cannot anticipate, and there the full row-miss latency lands on the critical path for every step. Simulation, compilation, database index traversal and some game engine work sit at that end of the range.
A further practical point: the nanosecond figure describes the DRAM device, not the total time the processor waits. Memory controller queueing, address translation, and the round trip across the interconnect all add to it, and on multi-socket or chiplet designs the extra can exceed the DRAM latency itself. Treat the calculator's output as the floor for a DRAM access, not the whole story. If you are working out how much memory a workload needs in the first place, our bandwidth requirement calculator and GPU cost calculator cover the capacity and cost side.
Rated Timings, JEDEC Speeds and What Actually Boots
A kit's advertised speed is usually not what the system runs at out of the box. Modules carry a small chip of configuration data describing a conservative baseline profile that any system can use, plus one or more vendor overclocking profiles holding the advertised speed and timings. Unless the faster profile is explicitly enabled in firmware, the machine runs the baseline, which is often several hundred MT/s slower with looser timings than the number on the box.
Two further limits apply. The processor's own memory controller has a ceiling that has nothing to do with what the modules can do, and populating more slots generally lowers the achievable speed because the electrical load on the bus rises. A four-module configuration frequently will not run the speed that the same modules reach in pairs. If you need to identify what is physically in a machine before calculating anything, Micron's FBGA and part decoder resolves the abbreviated markings printed on the chips themselves.
Arb Digital normalises numbers before comparing them, in hardware benchmarks and in marketing reporting alike.
Browse All Free Tools Talk To Our TeamCommon Mistakes to Avoid
- Comparing CL across different data rates — CL counts cycles, and cycles are not the same length on two kits running at different speeds.
- Halving the data rate before applying the formula — the factor of two thousand already accounts for the double data rate. Dividing by the clock instead of the transfer rate doubles the answer.
- Adding tRAS to the read path — it is a minimum row-open time that overlaps the other timings, not another stage in sequence.
- Assuming the advertised speed is what runs — without the vendor profile enabled in firmware, the machine uses the conservative baseline stored on the module.
- Treating DRAM latency as the whole wait — controller queueing and interconnect transit add to it, and on some designs they add more than the DRAM itself.
Related Free Tools From Arb Digital
Convert clock rates to periods with the frequency period calculator, move between data rate units with the bandwidth converter, size capacity with the data storage converter, plan link capacity with the bandwidth requirement calculator, or work in powers of two with the binary arithmetic calculator. The full free online tools hub lists every developer tool we publish.
Frequently Asked Questions
Latency equals CL multiplied by two thousand and divided by the data rate in MT/s. The two thousand accounts for DDR transferring twice per clock cycle and for converting seconds to nanoseconds.
No. Both work out to exactly 10 nanoseconds. The CL numbers differ because the clock is faster on the DDR5 kit, so each of its cycles is shorter.
Only when the two kits run at the same data rate. Across different data rates the cycle lengths differ, so CL cannot be compared directly and the nanosecond figure has to be calculated first.
They apply when the wanted address is in a row that is not currently open. tRP closes the active row and tRCD activates the new one, so the full delay is tRP plus tRCD plus CL, in cycles.
Because it is a minimum time a row must remain open once activated, which overlaps the other timings rather than following them. Adding it as a fourth stage substantially overstates the delay.
It depends entirely on the access pattern. Sequential streaming is limited by bandwidth because prefetching hides the latency, while pointer chasing and random lookups pay the full latency on every step.
Modules boot at a conservative baseline profile until the vendor overclocking profile is enabled in firmware. The processor's memory controller and the number of populated slots also cap what is achievable.
Data rate in MT/s multiplied by the bus width in bytes, divided by one thousand for gigabytes per second. It is a theoretical ceiling that real workloads do not reach.
This page explains a published timing conversion for educational purposes. Hardware compatibility, achievable memory speed and any firmware changes are governed by your motherboard and processor documentation.
