3 ms·
The thing about ECC vs. non-ECC. If you don't have ECC, you don't know silent bit corruption is happening, and when it's finally (if it's ever) discovered, ther
by dfeojm-zlib 7y ago
The thing about ECC vs. non-ECC. If you don't have ECC, you don't know silent bit corruption is happening, and when it's finally (if it's ever) discovered, there's nothing that can be done. ECC (SECDED) keeps data safer than it would be otherwise.
ECC is necessary for anything real or important based on the financial cost of losing data. For everything else, it can be optional.
Plus, don't forget the security issues of bitsquatting and other attacks that are the real results of silent bitflips.
DEF CON 19 - Artem Dinaburg - Bit-squatting: DNS Hijacking Without Exploitation
https://youtu.be/9WcHsT97suU https://youtu.be/9WcHsT97suU
- blackflame7000 7y agoAll computers do error checking. Here is a summary: Non-ECC - Checksum: parity bit BlockSize: 1 byte ECC - Checksum: 7 bits BlockSize: 8 bytes ZFS - Checksum: 256 bits BlockSize: ~128kb
- devonkim 7y agoIt’s a lot further than this though with unbuffered RAM, registered RAM in the mix affecting performance and such. Error detection and error correction are different and require different levels of parity codes. Standard RAM at one point (SIMMs in the 90s) detected errors but won’t ever correct them. ECC can detect more but error patterns and now correct error patterns up to so many bits. The issues are more subtle beyond hardware though - your OS kernel has to understand the detection from the BIOS / EFI and if the motherboard manufacturer decided not to opt for wiring in the checksum fail signal you will run blind to data corruption that’s potentially really subtle on typical consumer hardware. With some BIOSes RAM failures result in a hard panic and will hard reboot the machine (the idea being a crash is better than continuing with an error). For me, ECC (both UDIMM and RDIMM) today are so inexpensive it’s a no-brainer for builds for business.