Module Type and ECC Compatibility

Module Type and ECC Compatibility

Of everything spd-matchtable checks, these two — module type family and ECC presence — are the ones that determine whether a mixed kit boots at all, as opposed to merely running slower or less stable than hoped. Get a timing wrong and worst case you don't get a stable overclock; get one of these wrong and the system typically won't POST, full stop.

RDIMM vs. UDIMM: it's architectural, not electrical margin

An unbuffered DIMM (UDIMM) wires the memory controller's command, address, and clock signals directly to every DRAM chip on the module. A registered DIMM (RDIMM) — and its higher-capacity cousin, the load-reduced DIMM (LRDIMM) — inserts a register/buffer chip on the module itself between the memory controller and the DRAM chips: the controller talks to one buffer chip per module instead of directly to every DRAM die.

This exists to solve a real electrical problem in high-capacity server configurations: as you add more ranks and more DIMMs per channel, the command/address bus (shared across every installed module, as covered in Command Rate and tCWL) picks up more electrical loading than a consumer desktop memory controller is designed to drive directly. RDIMM pushes that loading problem onto a per-module buffer chip instead, letting a channel support far more total capacity/ranks than UDIMM could, at the cost of one extra buffering stage of latency.

Why mixing them doesn't just "maybe work worse": a consumer desktop memory controller is wired and trained to talk directly to DRAM dies — it has no protocol for talking to an RDIMM's register chip, and an RDIMM's register chip has no protocol for being addressed the way a bare UDIMM die expects. This is an incompatibility at the electrical/protocol level, not a timing-margin problem tighter settings could paper over, which is why spd-matchtable treats a detected RDIMM/UDIMM mismatch as a loud warning rather than folding it into the timing calculations at all — there's no timing fix for it.

ECC vs non-ECC: an extra data lane, not just extra bits

A non-ECC DDR4 module's data bus is 64 bits wide. An ECC module adds an extra 8-bit-wide chip specifically to carry error-correction code data — 72 bits total — computed from the 64 data bits to detect and correct single-bit errors (and detect, though not correct, many double-bit errors) on every access. This needs a memory controller actually wired to read/write that 9th chip and compute/verify the ECC syndrome; consumer platforms very commonly don't have that wiring or the CPU-side ECC logic active at all, even when a specific board technically has the extra pins routed.

Mixing ECC and non-ECC modules on the same channel means the "how wide is the bus per rank" assumption differs per module — most boards require either all-ECC or all-non-ECC populated for training to succeed at all, which is why this is checked and flagged the same way as the RDIMM/UDIMM case: a compatibility-family mismatch, not a timing question.

How spd-matchtable detects each

Both are read straight from SPD bytes that describe the module's fundamental construction, not anything timing-related:

• Module type (byte 0x03, low nibble): a JEDEC-defined code — 1 = RDIMM, 2 = UDIMM, 4 = LRDIMM, etc. — mapped internally to a "registered" vs. "unbuffered" family; a kit mixing families triggers the warning.
• ECC presence (byte 0x0D, the "bus width extension" bits): non-zero means the module physically has that extra ECC-carrying chip.

Both were cross-checked against this project's own live reference kit — all four of its modules read as UDIMM (module type 2) and non-ECC (extension bits 0), consistent with them being ordinary consumer Kingston Fury Beast sticks, before either check was trusted in code.