[fbdab103]

As a consumer does that matter? I understand server grade hardware wants the extra monitoring/diagnostic gizmos, but will the memory be corrected with the same efficiency as DDR4 ECC or is it an entirely neutered implementation?

[ElectricalUnion]

Not entirely neutered, but at least "data-at-rest" is protected, while "data-in-flight" is not.

[undersuit]

I'm not sold on on-die DDR5 ECC providing protecting.

On-die ECC allowed DDR5 to be competitive with DDR4. Is it really protecting your data at rest if the DDR5 die is running at such tolerances that it's correcting single bit errors from internal signalling issues every transaction? It's only single bit ECC, if something else outside of the die(Cosmic Ray, sudden voltage change, sudden temperature change) induces a bit to flip while the internal circuitry causes a different bit to flip your data is now corrupt.

https://www.atpinc.com/tw/blog/ddr5-what-is-on-die-ecc-how-i...

[fbdab103]

Is there any intuition about how frequently data-at-rest errors occur vs data-in-flight? Would the native DDR5 ECC get me 90% of the way there or is it so minor as to be effectively meaningless?

I assume it is going to take another decade to fully unwind Intel's ECC market segmentation. Trying to get a sense on if I should pay the ECC tax for my next build. Of course noting that as a consumer, I will probably never notice a flipped bit.

[lazide]

You’d ‘notice’ the flipped bits usually as rare, random, and impossible to reproduce crashes and lockups with the occasional data corruption.

Which is often background noise for home users, but no less problematic.

Often heat/load dependent too.