What is ECC memory, and when you need it

Error-correcting memory is one of the few parts of a build where the right answer becomes obvious once you know what the feature does. It catches a specific, rare failure, it costs money and a little latency, and it only works when three separate things line up. Most of the confusion around it comes from a fourth thing that shares the name and is not the same feature at all.

What ECC actually catches

A module without error correction stores the bits you asked it to store and hands back whatever it finds later. Occasionally what it finds is not what went in: a stray particle flips a cell, a marginal chip loses a charge, a signal on the bus arrives distorted. Nothing in the module knows, so the wrong value goes to the processor and the program acts on it.

An ECC module carries extra memory chips beyond the ones holding your data, and stores a checksum alongside every word. On each read the memory controller recomputes that checksum. A single flipped bit is corrected on the spot and logged; two flipped bits are detected but not corrected, and the machine stops rather than carrying on with data it knows is wrong.

Notice what that buys and what it does not. Error correction does not make memory faster, does not make it last longer, and does not save a module that is genuinely failing — it reports the failure sooner and more clearly, which is often worth more than the correction itself. What changes is that a silent wrong answer becomes a logged event, and whether that is worth paying for depends entirely on what the machine does. A workstation running a week-long simulation, a file server holding data that will be read back in five years, a database that must not write a corrupted row: for these, a wrong bit nobody notices is the expensive outcome. A gaming machine crashes, you restart it, and you have lost a few minutes.

On-die ECC is not ECC memory

This is the part that trips people, and DDR5 made it worse.

Every DDR5 chip has error correction built into the die. It is part of the standard rather than something one maker added — the densities DDR5 ships at make in-array bit errors frequent enough that correcting them inside the chip is what keeps yields workable. So a plain desktop DDR5 kit does carry error correction, in a real sense.

It is not the same feature. On-die correction covers errors inside the DRAM array and nothing else. It does its work before the data leaves the chip, so it does not cover the path from the module to the memory controller — the contacts, the traces on the board, the bus itself — and that path is where a meaningful share of memory errors happen. It also reports nothing: no counter to read, no log entry, no way for the operating system to learn that a correction happened or that corrections are becoming frequent. On-die ECC is a manufacturing measure that happens to help you. ECC memory is a system feature that tells you the truth about your own hardware.

The practical consequence is short: a DDR5 module having on-die correction tells you nothing about whether the machine has ECC memory. Those are two different questions with two different answers.

Unbuffered, registered, and load-reduced

Error correction is one axis. How a module is electrically driven is a separate one, and the two get conflated because server memory usually has both.

On an unbuffered module — a UDIMM in a desktop, a SO-DIMM in a laptop — the address and command lines run from the memory controller straight to every DRAM chip on the stick. It is the simplest arrangement and the lowest latency. The cost is electrical: each chip is a load on those lines, so the more chips and the more modules a channel carries, the harder the controller works and the sooner the signal stops being clean. That is why desktop platforms stop at a handful of slots and a ceiling on capacity per slot.

A registered module — an RDIMM — puts a register chip between the connector and the DRAM. The controller drives one load per module instead of dozens, and the register fans the signal out from there. This costs a clock cycle on address and command, and buys the ability to hang far more memory off a channel than an unbuffered design can carry.

A load-reduced module — an LRDIMM — buffers the data lines as well as the command lines. That removes the remaining electrical limit and lets the largest, most heavily ranked modules work at all, which is the only reason to accept the extra cost.

Nothing in that table is about error correction. Registered modules almost always carry it, because the platforms that take them want it — but unbuffered ECC modules exist and are ordinary parts. Our catalog holds several, and they sit on the desktop memory page rather than this one, because what puts a module on the server memory page is its form factor and nothing else: RDIMM and LRDIMM, the two spellings that mean a module is buffered.

The platform decides, not the module

An ECC module in a machine that does not support ECC does one of two things. It runs with the check bits ignored, or it does not run. Either way you have paid for a feature that is doing nothing.

Three things have to be present. The module must carry the extra chips. The memory controller — which lives inside the processor on every current platform — must be able to check them. And the firmware and the operating system must surface the result, because a correction nobody can see is not much better than none at all. Server and workstation platforms are built with all three. Consumer desktop platforms mostly are not, and where a desktop board and chip do handle unbuffered ECC, that is stated in the board's own documentation rather than implied by the socket. That is where this gets settled, and it is worth settling before the module is bought.

What we record, and what we do not

We record error-correction support on the module, as a field a datasheet either states or does not. Where a maker does not state it we leave the field empty rather than inferring it from a part number, so an empty field means we did not find the claim — not that the module lacks the feature. Every registered and load-reduced module in our catalog states it, and no laptop SO-DIMM does.

It is not something we compare on. Memory is compared on three figures — capacity, speed in MT/s, and CAS latency, higher being better on the first two and lower on the last — and error correction is in none of them, because it is not a figure that ranks. A module either carries the extra chips or it does not, and the question that follows is whether your platform can use them. The module is also the only place on this site where error correction is recorded at all: no processor or motherboard entry here carries a field for it, so a datasheet is where the question starts and the board's documentation is where it ends.

Two habits of this catalog are worth knowing before you read it. Server memory is listed as single modules rather than as kits, because channels are populated per slot and a board's slot count is what decides how many you buy. And the full timing tuple that desktop kits print is absent from every registered module here — makers publish the CAS latency and stop.

On which subject: the CAS numbers on registered DDR5 look alarming beside DDR4's, and every DDR5 module here carries a higher one than every DDR4 module does. They mean roughly the same wait, because a clock cycle gets shorter as the speed rises — how speed and latency work together has the arithmetic. And if the question underneath all of this is how much memory to buy rather than which kind, start with capacity, which moves far more, for far more machines, than error correction does.

Server memory and desktop RAM are each on one page, with specs from the datasheet and prices tracked over time.