Hacker News Reader

Comment by zdw | Hacker News Reader

Good news is that for DDR5, ECC is a required part of the spec and should be a feature of every module:

https://www.anandtech.com/show/15912/ddr5-specification-rele...

On die ECC is great for increasing reliability, if all else is equal, but if it doesn't report to the memory controller, and if the memory controller doesn't report to the OS, I think it will be worse than status quo, because all else won't be equal. With no feedback, systems are going to continue to run on the edge, but now detectable failures will all be multi-bit; because single bit errors are hidden.

Huh? Why would the memory controller not be updated accordingly? Also I have no idea about Linux or Mac, but Windows has had ECC support and active management for decades?

Normally, ECC has meant just the DIMM stores some extra bits, and the memory controller itself implements ECC-- writing the extra parity, and recovering when errors emerge (and halting when non-recoverable errors happen).

DDR5 includes on-die ECC, where the RAM fixes the errors before sending them over the memory bus.

This means if the bus between the processor and ram corrupts the bits-- tough luck, they're still corrupted. And it's unclear whether we're going to get the quality of memory error reporting that we're used to or get the desired halt-on-non-recoverable error behavior (I've not been able to obtain/read the DDR5 specification as yet).

Thank you!

It's part of the firmware first trend of fixing things at the firmware level before reporting problems up the stack. This makes it a real nightmare for systems integrators to do root cause analysis.

A whitepaper on DDR4 ECC by Micron that goes over some of the implementation challenges

https://media-www.micron.com/-/media/client/global/documents...

Is it built in as an added feature, or as the only way to make DDR5 reliable? My inner cynic is screaming the latter.

When the value add feature becomes a necessity, it’s not a value add any more.

I always wondered why isn't ECC built into the memory controller, the same hardware that runs the bus into L3 or the page mapper could checksum groups of cachelines.

It seems redundant to have every module come with its own checking hardware.

AFAIK it is built into the memory controller, at least for ECC UDIMM. There's an extra DRAM chip on the module for parity (generally 8+1), but it is memory controllers responsibility to utilize it (that's why not all CPUs support ECC)

ECC is a function of memory controller, not memory, on current systems. There's also usually some form of ECC on whatever passes for system bus, and internal caches have ECC as well.

For memory controller, parity/ECC/chipkill/RAIM usually involved simply adding additional memory planes to store correction data. I believe the rare exceptions are fully buffered memories where you have effectively separate memory controller on each module (or add-in card with DIMMs)

I read it to say that on die ecc is recommended but that dimm-wide ecc is still optional.

And now you have 8 bits of ecc per 32 data versus older DDR having 8 bits of ecc per 64 data. Hence the cost for dimm-wide ecc is going up.

Reply on news.ycombinator.com