Memory latency is the time between a processor issuing a request for data and that data arriving, measured in nanoseconds or in clock cycles. In computer memory and hardware generally, the term most often refers to the delay of a read from main memory (RAM), although every level of the memory hierarchy, from the L1 cache to the storage drive, has its own latency.
Latency is the counterpart to memory bandwidth. Bandwidth describes how much data can flow per second once a transfer is underway, while latency describes how long the first piece of data takes to arrive. Many workloads, especially those that follow pointers or access data unpredictably, are limited far more by latency than by bandwidth.
Where memory latency comes from
A load that misses every cache travels a long path. The core checks L1, L2 and L3 caches, the request then passes through the on-chip interconnect to the integrated memory controller, which schedules a command to the DRAM module, waits for the data and returns it to the core. Each stage adds delay.
Inside the DRAM chip, data sits in rows of a bank. To read it, the controller must activate the row, which copies it into the row buffer, then issue a column read. If a different row is already open, it must first precharge the bank to close that row. This is why the state of the DRAM has a large effect on latency.
| Parameter | What it measures | Effect on latency |
|---|---|---|
| CAS latency (CL) | Cycles from column read command to first data | Paid on every read |
| tRCD | Delay from row activation to column command | Paid when the row is not open |
| tRP | Time to precharge and close an open row | Paid when a different row must be opened |
| tRAS | Minimum time a row must stay open | Limits how quickly rows can be switched |
| tRFC | Time a rank is busy during refresh | Causes occasional long stalls |
The best case is a row buffer hit, where only the CAS latency applies. A row buffer conflict costs precharge, activation and CAS in sequence, which can roughly triple the DRAM portion of the delay.
Latency across the memory hierarchy
Processors hide main memory latency with multiple cache levels, each larger and slower than the one before. Typical values vary by design and clock speed, but the order of magnitude is consistent across modern desktop and server processors.
| Level | Typical capacity | Approximate latency |
|---|---|---|
| L1 data cache | 32 KB to 64 KB per core | About 4 to 5 cycles (around 1 ns) |
| L2 cache | 512 KB to 3 MB per core | About 12 to 18 cycles (3 to 5 ns) |
| L3 cache | 8 MB to over 100 MB shared | About 30 to 70 cycles (10 to 20 ns) |
| Main memory (DRAM) | 8 GB to several TB | About 60 to 120 ns |
| NVMe SSD | Hundreds of GB to many TB | Tens of microseconds |
The jump from L3 to DRAM is the critical one. At a clock speed of 5 GHz, a 100 ns memory access costs about 500 cycles, during which a modern core could otherwise have executed thousands of instructions. This gap is often called the memory wall.
CAS latency versus true latency in nanoseconds
The most common misconception is that a higher CL number always means slower memory. CAS latency is counted in memory clock cycles, so its real duration depends on the clock. The true CAS delay in nanoseconds equals CL multiplied by 2000, divided by the data rate in MT/s.
| Module | CAS latency | True CAS delay |
|---|---|---|
| DDR4-2400 | CL17 | About 14.2 ns |
| DDR4-3200 | CL16 | 10.0 ns |
| DDR4-3600 | CL18 | 10.0 ns |
| DDR5-4800 | CL40 | About 16.7 ns |
| DDR5-6000 | CL30 | 10.0 ns |
| DDR5-6400 | CL32 | 10.0 ns |
The table shows that DDR5-6000 CL30 and DDR4-3200 CL16 have the same CAS delay, even though the CL value doubled. True CAS delay has stayed near 10 to 15 ns for many DRAM generations; newer standards mainly increase bandwidth and capacity, not raw access speed.
CAS delay is also only one part of the total. A full load-to-use latency measured by software includes cache lookups, interconnect and controller queuing, so a desktop system with a 10 ns CAS delay typically measures 70 to 90 ns end to end.
How processors and software hide memory latency
Because latency cannot be eliminated, hardware and software work to overlap or avoid memory waits. These techniques explain why measured application performance often depends less on RAM timings than enthusiasts expect.
- Hardware prefetchers detect sequential or strided access patterns and fetch cache lines before the program asks for them.
- Out-of-order execution lets the core continue with independent instructions while a load is pending.
- Multiple outstanding misses allow a core to wait on many memory requests at once, turning latency into a bandwidth problem.
- Simultaneous multithreading switches to another thread’s instructions while one thread stalls.
- Cache-friendly data layouts, such as contiguous arrays instead of linked lists, make prefetching effective and reduce misses.
Workloads that defeat these mechanisms, such as graph traversal, hash table lookups and database index walks, are called latency-bound. For them, a few nanoseconds of lower latency translates directly into higher performance.
Practical factors that raise or lower memory latency
Several platform choices influence latency beyond the module’s printed timings. Understanding them helps avoid spending money on faster RAM that brings no measurable gain.
| Factor | Effect | Practical guidance |
|---|---|---|
| Memory profile not enabled | RAM runs at slow default timings | Enable XMP or EXPO in firmware |
| Controller and fabric clock ratio | Mismatched ratios add delay | Prefer data rates that keep a 1:1 or recommended ratio |
| Remote NUMA node | Access to another socket’s memory is slower | Pin threads and memory to the same node |
| ECC and registered modules | Small added delay for buffering | Accept it where reliability matters more |
| LPDDR5 in laptops | Often higher latency than desktop DDR5 | Expect power savings, not lower latency |
Gaming benchmarks are a typical case where latency matters, because game engines touch large, scattered data sets each frame. Even there, a large L3 cache usually helps more than tighter RAM timings, since it avoids the DRAM trip altogether.
Understanding it simply
Imagine a chef who keeps a few spices on the counter, more in a cupboard and the rest in a storeroom down the hall. Memory latency is how long the chef waits for an ingredient to arrive. The counter is instant, the cupboard takes a moment, and the storeroom trip is slow enough to stall the cooking.
Computers work the same way. The processor keeps recent data in small, fast caches close by, while main memory is larger but farther away. Lower latency means shorter waits, and it matters most for programs that jump around unpredictably instead of reading data in neat order.
Applied in practice
A database administrator tunes a server that answers many small queries through index lookups. Monitoring shows CPU cores at moderate load, yet query times are poor. Profiling reveals frequent last-level cache misses, and many queries run on threads scheduled on one socket while their data sits in the other socket’s memory.
The administrator enables NUMA-aware memory allocation and pins database worker threads to the node that owns their data. Remote memory accesses fall sharply, and average query response time improves noticeably without any hardware purchase. The case shows that reducing effective memory latency can matter more than buying faster RAM.