2 ms·
It's really that simple. > the complexities of having ECC protection only on the link That's not SECDED, since it can't correct a bitflip that occurs somewher
by crotchfire 3y ago
It's really that simple.
> the complexities of having ECC protection only on the link
That's not SECDED, since it can't correct a bitflip that occurs somewhere other than on the link, nor can it detect a double bitflip in those situations.
SECDED. Just ask for SECDED.
Even the Linux kernel knows about this:
# cat /sys/devices/system/edac/mc/mc1/csrow3/edac_mode
SECDED
SECDED. Just ask for SECDED.
- wtallis 3y ago> That's not SECDED, since it can't correct a bitflip that occurs somewhere other than on the link You're just making up arbitrary rules. The term SECDED does not incorporate any guarantees about which part of a system it applies to. It's just a mathematical statement about the strength of the ECC in use plus the implication that detectable but uncorrectable errors are reported. What you're looking for requires more words to fully specify, probably including the term "end to end".
- jeffbee 3y agoYour mantra is sort of hilarious because with current technology SECDEC is the worst ECC you can buy. If that's what you are getting on a DDR5 server today, the most likely reason is your integrator has made a mistake.