Hacker News Reader

Comment by amelius | Hacker News Reader

With error correction?

When's the last time anyone made non-ECC registered or buffered memory modules?

ECC memory still isn't standard on consumer PCs, I don't think — although all DDR5 memory includes some error correction, manufacturers suggest it's not as robust (https://www.corsair.com/us/en/explorer/diy-builder/memory/is...).

Consumer PCs aren't relevant here because they only use unbuffered DIMMs and cannot accept RDIMMs, LRDIMMs, MCRDIMMs, etc., which is part of why consumer desktops are limited to much lower memory capacities than servers. (The other limitation being the number of memory channels.)

Intel is to blame for this status quo. AMD is fixing it, hopefully Intel will start shipping ECC support for their consumer products soon...

Are you referring to the status quo of consumer PCs not supporting ECC memory, or the status quo of consumer PCs not supporting buffered memory of various flavors? Because AMD's not doing anything about the latter, and DDR5 made it even harder to support both buffered and unbuffered modules on the same platform.

It is little better than speculation but the photo shown suggests 9 bits.

5 columns of chips on each side indicates an extra 8 bits for each 32-bit subchannel, which is pretty common for DDR5 RDIMMs. But the article mentions a 72-bit interface (the standard for DDR5 ECC UDIMMs and earlier ECC DIMM standards) rather than an 80-bit interface, so there's at least some cause for doubt about which level of ECC these modules provide.

> 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.

Reply on news.ycombinator.com