Refresh Timing tRFC

Refresh Timing: tRFC1, tRFC2, tRFC4

Why DRAM needs refreshing at all

Each bit in a DRAM chip is stored as charge on a capacitor. Capacitors leak. Left alone, every bit would decay toward an indeterminate state within tens of milliseconds. So the memory controller periodically issues a REFRESH command to every bank, which reads each row and immediately rewrites it — the same physical restore-on-read behavior described in Primary Timings CL tRCD tRP tRAS tRC, just applied automatically and comprehensively rather than by an explicit access. This happens constantly, on the order of every ~7.8 microseconds per refresh command (JEDEC's standard refresh interval, tREFI — not something SPD encodes, since it's a controller-side schedule rather than a device limit).

tRFC is how long the memory bus must wait after issuing a REFRESH command before it can issue anything else. During that window the chip is busy internally cycling through rows; no other command can be serviced.

Why bigger chips need longer tRFC

A refresh command doesn't refresh one row — it refreshes rows across all banks internally, and the more total capacity a die has, the more rows there are to get through per refresh cycle. This is precisely why tRFC scales with die density, not with module capacity or rank count:

• 8Gb dies: tRFC1 around 350ns (this reference kit's two dual-rank 16GB sticks, built from 8Gb dies)
• 16Gb dies: tRFC1 around 550ns (this reference kit's 16GB single-rank stick, built from 16Gb dies)

That's a real, measured 200ns difference driven purely by die density — nothing to do with total module capacity, since a 16GB module built from 8Gb dies (dual-rank) needs less refresh time than a 16GB module built from 16Gb dies (single-rank). This is exactly the situation spd-matchtable found in its own reference kit: two 16GB modules of identical capacity but different tRFC1 requirements because of different underlying die density.

Why this dominates the "worst case" for a mixed kit

Because tRFC is a fixed time cost paid on every refresh, and refreshes happen roughly every 7.8μs regardless of what else is going on, a longer tRFC isn't a one-time penalty — it's continuous background overhead that eats into available bandwidth the whole time the system is running. In a mixed kit, whichever installed module has the highest tRFC1 (in nanoseconds) sets the system-wide requirement, since every module shares the same command bus and BIOS applies one tRFC value globally, not per-slot.

This is why, in this tool's own worst-case table, tRFC1 is consistently the parameter with the largest number of required cycles by a wide margin — not because it's inherently the "worst" timing, but because its governing value in nanoseconds (hundreds of ns) dwarfs every other timing on this page (tens of ns), even before converting to cycles.

tRFC1 / tRFC2 / tRFC4 — three refresh granularities

DDR4 SPD actually encodes three refresh timings, not one:

• tRFC1: refreshing a full bank/row set at standard granularity — the conservative, always-safe value, and the one this tool's match table uses.
• tRFC2: a shorter "fine granularity" refresh mode (finer refresh commands, more of them, each shorter) — optional, and not all controllers use it.
• tRFC4: an even finer granularity mode, shorter still per-command.

spd-matchtable decodes and reports all three (visible via --json), but the match table specifically uses tRFC1 because it's the mode every DDR4 memory controller is guaranteed to support — tRFC2/tRFC4 fine- granularity refresh is an optional controller feature, and assuming it's available would be exactly the kind of "usually true, sometimes silently wrong" assumption this tool tries not to make.