Someone correct me if I am wrong but isn't DDR5 ECC by default? I know this from an anecdote that I used to enable XMP all the time in my builds and run RAM stability tests, none ever caught anything but on my DDR5 builds, if I turned on XMP and played a game for an extended period, I'd get a BSOD after 4-5 hours, which I figured is the ECC built into DDR5 flagging something unexpected.
ddr5 ecc is on-die ecc, that is built in with the ram die, while the regular ecc relies on extra bit width(72 bit instead of 64 bit) going all the way into CPU such that it's detectable also on cpu (hence OS level) side, which also ensures the error during transmission get corrected as well.
There are two ECC types in DDR5: on-die ECC and external.
All have on-die ECC, which always operates. It is relatively rare to have external; something like Kingston Server Premier, and then you would need a motherboard to support it e.g. some of the Asrock ones, or just a server motherboard (MSI D3051, etc.)
AFAIK there's a performance hit using external ECC, as it adds an extra cycle. I think errors get reported to the OS differently. Beyond that, I know nothing.
Just to dispel this myth - here's all my electronic devices that have replaceable memory, and which of them support ECC:
ECC support (and using ECC memory):
- my old home server (an old Xeon E5-2630v2, DDR3, Supermicro MB, slated for disposal)
- my new home server (a Ryzen V3C48 embedded system, solid-run, uses DDR5 SO-DIMM)
- my desktop (a Ryzen 1700X, DDR4, ASrock mainboard)
Broken ECC due to BIOS:
- my laptop (HP Elitebook 845 G9, Ryzen 6950HS, DDR5 SO-DIMM, CPU supports ECC; BIOS hangs on boot when I insert ECC memory)
No ECC:
- none, actually.
(dis-)honorable mentions, no ECC, but memory not replaceable anyway:
- my geriatric wifi router (some TP-link, about to be ditched)
- my 2 extra wifi APs (also some TP-link)
This rate of ECC support is probably a bit exceptional, but… the primary reason ECC support is hit-and-miss is that Intel decided to fuse it off on their desktop CPUs to do market segmentation.
The fact that a handful of enthusiasts on a technology forum have machines with ECC has zero relevance to whether it is rare. It is. Virtually all consumer prebuilt x86 PCs lack ECC. The majority of DIY builds are Intel, and their enthusiast Core CPUs lack ECC. Most Ryzen boards do not actually support it.
When people say ECC is rare, they’re not talking about you.
> AFAIK there's a performance hit using external ECC, as it adds an extra cycle.
This may be the case in some specific implementations but nothing in the DDR5 spec prevents you from pipelining the ECC calculations alongside the cycles you already need for cache management anyway. The memory itself and the interface don't care, they just do 72bit instead of 64bit.
I base this on my day-to-day messing with firmware for some Arm microcontroller implementations, and it is only a guess that PC would be similarly affected and only affecting latency, not throughput. But, in this specific case, I don't know.
I only learned enough to buy some and put it in my last build, and I've only gone as far as checking that dmesg says the memory bus is 72 bits wide; no benchmarks, no overclocking. Then again, my goal is stability and not performance.
The default DDR5 ECC is not exposed to the outside, not reported to the OS.
You only caught errors on DDR5 because it's stability is very brittle. Market forces push it to the limit - everybody cares about the MT/s and runs XMP unlike previous generations.
DDR5 seems to have optimistic XMP settings, whereas DDR3/4 were more conservative.
I have, however, had very good luck so far just buying faster DDR5 and then running it a little slower at the same timings, which is how I arrived at the idea that DDR5 XMP is usually too fast to be actually stable.
XMP profiles are still seemingly more conservative for DDR4, since I would typically run my 3200MHz DDR4 at 3840MHz. That stopped once I added a couple mismatching sticks though, now I have to run the set at 3105MHz or the system won't POST. Not a particularly big deal.
DDR5 uses on-die ECC to improve chip yield (AFAIK.) Any errors are not reported to the OS so the BSODs you experience are not resulting from reported ECC errors. They could be the result of uncorrected memory errors that are undetected but cause the OS to crash.
Some DDR4 also uses on-die ECC. The specs for the Raspberry Pi 4B list DDR4 ECC RAM.
