> a 72-bit interface (the standard for DDR5 ECC UDIMMs

How does that work, when you only have 4 bits of ECC per 32 bits of data? Is the calculation done in two-transfer bursts?

(Apparently EC4 and EC8 are useful keywords for this.)

DDR5 uses burst length 16, so think of it as 512 data bits with 64 ECC bits out of 576 total.

Sure, it is, but that doesn't explain how it works. Previous generations made it simple, they did SECDED ECC (or sometimes chipkill) one transfer at a time no matter what the transaction size was. DDR5 EC4 can't do that, so what does it do?

And does EC8 do SECDED one transfer at a time, or does it do something more resilient?

(And sure technically it's up to the memory controller to implement, but are different controllers doing different things with DDR5?)

72-bit DDR5 is nonstandard to begin with and I assume AMD and Intel are using undocumented ECC codes. There might be hints in patents.

AIUI, I don't think folks will be able to read the ECC values from these chips. They may/should silently fix issues but you won't be able to monitor the chips like you can with regular ECC RAM using tools like ras. So they may help with bit flips but won't help identifying bad sticks, I think.

The ECC used by buffered modules is the "regular ECC RAM" where the memory bus is widened (and chip count increased) to accommodate carrying the extra ECC information between the DRAM controller on the CPU and the memory modules, with the ECC calculations and corrections done on the CPU and errors surfaced to the firmware and/or OS, giving ECC protection not just for data at rest but also in transit. But the actual ECC bits computed, transferred and stored for each word of DRAM are never directly exposed to software to access.

There is also on-die ECC used by all recent DRAM as a consequence of shrinking memory cell sizes and spacing in the latest DRAM fabrication processes. That on-die ECC is what's unfortunately invisible to the host system, and only really useful for protecting data at rest, not in transit. The existence of on-die ECC has most commonly been publicized in the context of DDR5, but really has nothing to do with what DRAM interface standard is used because the on-die ECC happens entirely on each individual die.

> only really useful for protecting data at rest, not in transit

Which makes it more annoying that normal DDR doesn't also have the ability to add link-ECC like LPDDR.