13 ms·

Just to offer a partial counterpoint to the popular "ECC is a must for real work" sentiment, I've ran many 60-day simulations where a few bit errors would be co

Just to offer a partial counterpoint to the popular "ECC is a must for real work" sentiment, I've ran many 60-day simulations where a few bit errors would be completely irrelevant. Many physics simulations include internal checks (that must be there regardless of ECC, for algorithmic reasons) that would catch virtually all such issues. While a bit error could certainly crash the simulation, long running simulations can be resumed from checkpoints with minimal loss of time and the probability of a crash is still very low for most real workloads. In truth, there are plenty of good reasons, both for data integrity and security, to have ECC. However, there are real costs to ECC too - 10-30% immediate performance overhead (depending on your application) and much more than that for memory-bound workloads (due to lower frequencies and subtiming issues), not to mention hardware cost efficiency. Instead of oscillating between "ECC for everything" and "ECC is useless" people should rationally compare the costs and benefits for their specific workload and choose accordingly.

dna_polymerase 9y ago
Thank you! That sentiment on HN about how "Everything should have ECC" really grinds my gears. There is no need for ECC in your iPhone or on your MacBook. Your average emoji-laden WhatsApp Conversation with your friends does not require Bit Error Correction. People who really need ECC do exactly what you just mentioned: Evaluate, and often enough they will find little to gain from ECC.
- sitkack 9y ago
  > There is no need for ECC in your iPhone or on your MacBook. Scientists, Engineers and Economists shouldn't use a Phone or MacBook? Your handle is ironic. The lack of ECC is a method to artificially segment markets and nothing more. Not ECC, but "single bit errors" can be fatal in other domains [0] [0] https://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail https://gizmodo.com/382026/a-cellphones-missing-dot-kills-tw...
  - sixbrx 9y ago
    I imagine bit errors are highly unwanted on any domain when they occur in pointers, especially on those that are written through. Some languages make that more likely than others of course with heavy use of references.
  - Bromskloss 9y ago
    Wow, that story is like Romeo and Juliet, or Pyramus and Thisbe.
  - kpxxx3 9y ago
    Lol that is not a single bit error in the slightest. Like that’s the same as reducing airline accidents to just being one little mistake or similarly just casting off challenger as a materials failure.
- jmh530 9y ago
  But when you need ECC, you really need it. My FreeNAS server has like 32GB or ECC memory because it runs ZFS, which basically doesn't work unless you have ECC memory. However, my desktop computer or my laptop don't need it. When you need ECC, use it, but if you don't need it, then no biggie.
  - rightos 9y ago
    Why does ZFS "really need" ECC? I have a few friends running freenas on just old machines without ECC, no issues so far a few years in.
    - slobotron 9y ago
      If anything, ZFS checksumming lets you get by without ECC and still be confident in your data...
      - kobeya 9y ago
        No because the checksums are cached in ram and not verified against the disk when an error occurs.
        slobotron 9y ago
        Thanks for catching that - my statement was definitely too strong in implying data invulnerability. I was hinting that you still get a bit of extra protection with ZFS over other filesystems, both on Non-ECC RAM. There is a chance with a stuck/corrupt bit that checksum will fail and you will get a read error. I interpreted OP as saying ECC is a must for ZFS, but I don't think you are more prone to corruption that any other FS? I'm basing my understanding on this: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...
        raattgift 9y ago
        Yes-and-no. In the most general case the checksum of data block A lives in the parent block B. B's checksum in turn lives in its parent block. And so forth all the way to the root of the Merkle tree. These checksums are fixed exactly once, in the zio pipeline, as a dirtied buffer is being passed through it during a write operation. The checksum then stays on disk in that form in block B for as long as block A is reachable. In the read case, checksum validation is done at the vdev_{raidz,mirror,...}.c level and repaired there if possible e.g. from another element of the mirror; recovery is also possible in the case of copies=N (N > 1). Generally, the checksums of read data and metadata are not used once a buffer is successfully in the ARC. (However, compare arc_buf_{freeze,thaw}(), which one can enable, and which will happily cause panics if ARC buffers are corrupted whether through physical problems (e.g. in memory, in a bus, in the CPU) or software error in the kernel.) Block B may already be in cache for some other reason, in which case the in-memory checksum is used (this is the "yes" part of "yes-and-no"); otherwise, block B will have to be fetched before block A, because block B is where A's checksum lives. Block B may be evicted from ARC long before block A is evicted; any read() or similar call that needs data from A will not result in B being read back into memory. A buffer kept in ARC and used as the source of subsequently-dirtied data will have its checksum generated anew, just like the fresh write above. Obviously if the data it is dirtied with is bad, it will go to disk and its parents will have a checksum reflecting the bad data. However, the source of the badness need not be within the transient dirtied buffer, nor in a long-resident ARC buffer; userland memory can be corrupted too. If one has bad memory than bad data may end up on disk, checksummed in such a way that the badness will not be detected by the ZFS subsystem. But this is really no different from any other RAID-like data-validating system or a traditional one-disk filesystem which doesn't checksum. If bits are flipped in userland data that is ultimately subjected to a write(2) call (etc., think mmap()), no filesystem can reasonably expect to do anything other than write out the data handed to it via the system call. Like any other filesystem, ZFS has its own metadata for tracking allocations, object metadata, and in generating the branch-to-root Merkle tree. The wrong memory corruption (and this has happened in software during ZFS development) can result in data loss or even a pool too damaged to be imported (go to backups). ZFS is not especially more exposed to that than any other filesystem. Since the arrival of compressed ARC and crypto, only a small fraction of ARC buffers are kept uncompressed or unencrypted in memory at any time (this is controlled by the dbuf cache tunables). Bitflips in any encrypted-in-memory ARC buffer will be caught (noisily) if the buffer is subsequently read or modified, since a decryption will be done at that time and would fail under a single modified bit. Many possible corruptions in compressed-in-memory data will also be caught depending on the type of compression used when the buffer was first written out to disk. In neither case is the ZFS checksum involved in the catching of such corruptions. Finally, this still won't protect against corruptions in userland, corruptions which hit the various data structure that point to buffers in ARC, or corruptions in the text segments in the zfs subsystem or elsewhere in the kernel. However, ZFS is not realisically more fragile to such corruptions than any other filesystem.
- frou_dh 9y ago
  It’s odd to talk about “needs” like this. iPhones don’t “need” the Secure Enclave either, but never the less it’s great that they have it. It’s some kind of snobbery to advocate that good technology should be held back until non-enterprise plebs demonstrate that they are deserving of it. Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it?
  - tokenizerrr 9y ago
    > Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it? Everyone who buys the product and doesn't require the technology, because they'll be spending more money on something they don't need or use.
    - frou_dh 9y ago
      How does someone “not use” ECC RAM when their computer contains it? Computer reliability should be a rising tide. Up-and-to-the-right is the goal.
    - LeifCarrotson 9y ago
      If ECC was the normal product that went into everything, and someone invented "unverified" RAM to get a tiny speed boost and slightly decreased cost, how much do you think the actual price difference would be? I expect it would be tiny. It's a political decision by Intel to make ECC an Xeon-only product which has resulted in the vast majority of the price difference. The silicon die area required for it really doesn't cost that much more - often, the area is present on the consumer dies but just disabled so they can charge a lot more to the enterprise customers who actually require it. And political decisions like that make a lot of HN users unhappy. As Joel Spolsky said in https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-duckies/ https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-...: > Working my way backwards, this business about segmenting? It pisses the heck off of people. People want to feel they’re paying a fair price.... And God help you if an A-list blogger finds out that your premium printer is identical to the cheap printer, with the speed inhibitor turned off. Everyone knows that ECC parts are nearly identical to the cheap parts, with the ECC module turned off. But there's no boycott, because there are (were?) no other options, like there might be for a printer company. ECC segmentation is just something everyone knows and resents.
- mozumder 9y ago
  ECC increases reliability on older systems as well, increasing lifespan of any product. Silicon degradation is a thing.
- muraiki 9y ago
  Bitsquatting refers to registering a domain name one bit different from the target domain name. The intent is that a memory error will cause someone to get the bitsquatted site instead of the legitimate one. "During the logging period there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses. When not counting 3 events that caused extraordinary amounts of traffic, an average of 59 unique IPs per day made HTTP requests to my 32 bitsquat domains." http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html Overheating can be a cause of bit errors, and heat is a concern in mobile devices and laptops.
  - haikuginger 9y ago
    Now I'm curious to see how different user agents would handle SSL validation for bit errors at different points in the process.
Retric 9y ago
ECC has no where near 30% performance overhead. In terms of speed it's ~2–3 percent slower worst case, and memory is only one component of overall performance lowering the impact further. More importantly, bit errors are not evenly distributed with some users seeing vastly more errors.
- TrainedMonkey 9y ago
  Can you elaborate on that distribution?
  - Retric 9y ago
    The main causes are altitude/background radiation, temperate, overclocking, faulty parts etc. But, memory can have 100+x the normal failure rates without being particularly noticeable in day to day operations. The value of ECC is often more to detect errors than to correct them. Remember, if you have 10 errors an hour then you unlikely to see them in a 20 second memory test. In practice out of 10,000 machines you might have 1/2 your errors on 10 of them. Critically, if you have ECC memory and you both detect and replace those 10 machines the apparent rate of failures then drops. PS: This is a little dated (09) and only from a single set. But, still an interesting introduction: https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf "Around 20% of DIMMs in Platform A and B are affected by correctable errors per year, compared to less than 4% of DIMMs in Platform C and D. ... About a third of all machines in the fleet experience at least one memory error per year (see column CE Incid. %) and the average number of correctable errors per year is over 22,000. "
    - keldaris 9y ago
      As I understand it, the situation is even better (as in, less errors) than that with DDR4. Unfortunately, all the published data I could find is woefully out of date. Still, even if you generously assume something on the order of one correctable memory error per machine year, how many of those errors do you actually care about? Unless you have 100% memory utilization for 24/7 critical tasks, most of those errors probably don't even matter. EDIT: the least out of date reference I could find is a blog post by Jeff Atwood, where he concludes that based on the available literature ECC-correctable errors are quite rare. [1] [1] https://blog.codinghorror.com/to-ecc-or-not-to-ecc/ https://blog.codinghorror.com/to-ecc-or-not-to-ecc/
sillysaurus3 9y ago
Many physics simulations include internal checks (that must be there regardless of ECC, for algorithmic reasons) that would catch virtually all such issues. Hmm, like what? I've run many simulations too and had the opposite experience. It's hard to implement checks because your algorithm defines how the simulation should permute over time. While a bit error could certainly crash the simulation, long running simulations can be resumed from checkpoints with minimal loss of time and the probability of a crash is still very low for most real workloads. Not really. Your algorithm determines how the simulation plays out, so you can't really notice small errors until much later. By then it's hard to roll back to an earlier state unless you're saving 64GB snapshots.
- twic 9y ago
  I don't know about checks, but any algorithm which works by iteratively converging on a solution, like Newton-Raphson and its bigger relatives, has quite a lot of bit-error tolerance built in.
  - keldaris 9y ago
    That's right, any iterative solver method (which already encompasses most of the low level numerical solvers used in physics today) or, more generally, any method that algorithmically guarantees satisfying a particular mathematical constraint after each timestep (say, if you're enforcing fluid incompressibility at each timestep, most* single bitflips will not cause errors that would accumulate over time), etc. [*] There are exceptions in specific circumstances most of which would produce obviously wrong results or crash the simulation outright. However, I'm not claiming that single bitflips are never an issue for simulations, only that it happens much less often than people sometimes think.
    - sillysaurus3 9y ago
      If a one-bit error causes the sign bit to flip, your position can go from 129,121.34 to -129,121.34. Obviously this is rare, but it seems mistaken to say that the simulation's parameters can prevent errors arising from this. Also, it's not just physics simulations that are at risk. Voxel renderings are especially susceptible to one-bit errors.

dna_polymerase 9y ago

Thank you! That sentiment on HN about how "Everything should have ECC" really grinds my gears. There is no need for ECC in your iPhone or on your MacBook. Your average emoji-laden WhatsApp Conversation with your friends does not require Bit Error Correction. People who really need ECC do exactly what you just mentioned: Evaluate, and often enough they will find little to gain from ECC.

sitkack 9y ago
> There is no need for ECC in your iPhone or on your MacBook. Scientists, Engineers and Economists shouldn't use a Phone or MacBook? Your handle is ironic. The lack of ECC is a method to artificially segment markets and nothing more. Not ECC, but "single bit errors" can be fatal in other domains [0] [0] https://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail https://gizmodo.com/382026/a-cellphones-missing-dot-kills-tw...
- sixbrx 9y ago
  I imagine bit errors are highly unwanted on any domain when they occur in pointers, especially on those that are written through. Some languages make that more likely than others of course with heavy use of references.
- Bromskloss 9y ago
  Wow, that story is like Romeo and Juliet, or Pyramus and Thisbe.
- kpxxx3 9y ago
  Lol that is not a single bit error in the slightest. Like that’s the same as reducing airline accidents to just being one little mistake or similarly just casting off challenger as a materials failure.
jmh530 9y ago
But when you need ECC, you really need it. My FreeNAS server has like 32GB or ECC memory because it runs ZFS, which basically doesn't work unless you have ECC memory. However, my desktop computer or my laptop don't need it. When you need ECC, use it, but if you don't need it, then no biggie.
- rightos 9y ago
  Why does ZFS "really need" ECC? I have a few friends running freenas on just old machines without ECC, no issues so far a few years in.
  - slobotron 9y ago
    If anything, ZFS checksumming lets you get by without ECC and still be confident in your data...
    - kobeya 9y ago
      No because the checksums are cached in ram and not verified against the disk when an error occurs.
      - slobotron 9y ago
        Thanks for catching that - my statement was definitely too strong in implying data invulnerability. I was hinting that you still get a bit of extra protection with ZFS over other filesystems, both on Non-ECC RAM. There is a chance with a stuck/corrupt bit that checksum will fail and you will get a read error. I interpreted OP as saying ECC is a must for ZFS, but I don't think you are more prone to corruption that any other FS? I'm basing my understanding on this: http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/ http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-yo...
      - raattgift 9y ago
        Yes-and-no. In the most general case the checksum of data block A lives in the parent block B. B's checksum in turn lives in its parent block. And so forth all the way to the root of the Merkle tree. These checksums are fixed exactly once, in the zio pipeline, as a dirtied buffer is being passed through it during a write operation. The checksum then stays on disk in that form in block B for as long as block A is reachable. In the read case, checksum validation is done at the vdev_{raidz,mirror,...}.c level and repaired there if possible e.g. from another element of the mirror; recovery is also possible in the case of copies=N (N > 1). Generally, the checksums of read data and metadata are not used once a buffer is successfully in the ARC. (However, compare arc_buf_{freeze,thaw}(), which one can enable, and which will happily cause panics if ARC buffers are corrupted whether through physical problems (e.g. in memory, in a bus, in the CPU) or software error in the kernel.) Block B may already be in cache for some other reason, in which case the in-memory checksum is used (this is the "yes" part of "yes-and-no"); otherwise, block B will have to be fetched before block A, because block B is where A's checksum lives. Block B may be evicted from ARC long before block A is evicted; any read() or similar call that needs data from A will not result in B being read back into memory. A buffer kept in ARC and used as the source of subsequently-dirtied data will have its checksum generated anew, just like the fresh write above. Obviously if the data it is dirtied with is bad, it will go to disk and its parents will have a checksum reflecting the bad data. However, the source of the badness need not be within the transient dirtied buffer, nor in a long-resident ARC buffer; userland memory can be corrupted too. If one has bad memory than bad data may end up on disk, checksummed in such a way that the badness will not be detected by the ZFS subsystem. But this is really no different from any other RAID-like data-validating system or a traditional one-disk filesystem which doesn't checksum. If bits are flipped in userland data that is ultimately subjected to a write(2) call (etc., think mmap()), no filesystem can reasonably expect to do anything other than write out the data handed to it via the system call. Like any other filesystem, ZFS has its own metadata for tracking allocations, object metadata, and in generating the branch-to-root Merkle tree. The wrong memory corruption (and this has happened in software during ZFS development) can result in data loss or even a pool too damaged to be imported (go to backups). ZFS is not especially more exposed to that than any other filesystem. Since the arrival of compressed ARC and crypto, only a small fraction of ARC buffers are kept uncompressed or unencrypted in memory at any time (this is controlled by the dbuf cache tunables). Bitflips in any encrypted-in-memory ARC buffer will be caught (noisily) if the buffer is subsequently read or modified, since a decryption will be done at that time and would fail under a single modified bit. Many possible corruptions in compressed-in-memory data will also be caught depending on the type of compression used when the buffer was first written out to disk. In neither case is the ZFS checksum involved in the catching of such corruptions. Finally, this still won't protect against corruptions in userland, corruptions which hit the various data structure that point to buffers in ARC, or corruptions in the text segments in the zfs subsystem or elsewhere in the kernel. However, ZFS is not realisically more fragile to such corruptions than any other filesystem.
frou_dh 9y ago
It’s odd to talk about “needs” like this. iPhones don’t “need” the Secure Enclave either, but never the less it’s great that they have it. It’s some kind of snobbery to advocate that good technology should be held back until non-enterprise plebs demonstrate that they are deserving of it. Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it?
- tokenizerrr 9y ago
  > Just give everyone the good technology as much as is possible. Who’s it hurting if some subjectively underutilise it? Everyone who buys the product and doesn't require the technology, because they'll be spending more money on something they don't need or use.
  - frou_dh 9y ago
    How does someone “not use” ECC RAM when their computer contains it? Computer reliability should be a rising tide. Up-and-to-the-right is the goal.
  - LeifCarrotson 9y ago
    If ECC was the normal product that went into everything, and someone invented "unverified" RAM to get a tiny speed boost and slightly decreased cost, how much do you think the actual price difference would be? I expect it would be tiny. It's a political decision by Intel to make ECC an Xeon-only product which has resulted in the vast majority of the price difference. The silicon die area required for it really doesn't cost that much more - often, the area is present on the consumer dies but just disabled so they can charge a lot more to the enterprise customers who actually require it. And political decisions like that make a lot of HN users unhappy. As Joel Spolsky said in https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-duckies/ https://www.joelonsoftware.com/2004/12/15/camels-and-rubber-...: > Working my way backwards, this business about segmenting? It pisses the heck off of people. People want to feel they’re paying a fair price.... And God help you if an A-list blogger finds out that your premium printer is identical to the cheap printer, with the speed inhibitor turned off. Everyone knows that ECC parts are nearly identical to the cheap parts, with the ECC module turned off. But there's no boycott, because there are (were?) no other options, like there might be for a printer company. ECC segmentation is just something everyone knows and resents.
mozumder 9y ago
ECC increases reliability on older systems as well, increasing lifespan of any product. Silicon degradation is a thing.
muraiki 9y ago
Bitsquatting refers to registering a domain name one bit different from the target domain name. The intent is that a memory error will cause someone to get the bitsquatted site instead of the legitimate one. "During the logging period there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses. When not counting 3 events that caused extraordinary amounts of traffic, an average of 59 unique IPs per day made HTTP requests to my 32 bitsquat domains." http://dinaburg.org/bitsquatting.html http://dinaburg.org/bitsquatting.html Overheating can be a cause of bit errors, and heat is a concern in mobile devices and laptops.
- haikuginger 9y ago
  Now I'm curious to see how different user agents would handle SSL validation for bit errors at different points in the process.

Retric 9y ago

ECC has no where near 30% performance overhead. In terms of speed it's ~2–3 percent slower worst case, and memory is only one component of overall performance lowering the impact further. More importantly, bit errors are not evenly distributed with some users seeing vastly more errors.

TrainedMonkey 9y ago
Can you elaborate on that distribution?
- Retric 9y ago
  The main causes are altitude/background radiation, temperate, overclocking, faulty parts etc. But, memory can have 100+x the normal failure rates without being particularly noticeable in day to day operations. The value of ECC is often more to detect errors than to correct them. Remember, if you have 10 errors an hour then you unlikely to see them in a 20 second memory test. In practice out of 10,000 machines you might have 1/2 your errors on 10 of them. Critically, if you have ECC memory and you both detect and replace those 10 machines the apparent rate of failures then drops. PS: This is a little dated (09) and only from a single set. But, still an interesting introduction: https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf https://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf "Around 20% of DIMMs in Platform A and B are affected by correctable errors per year, compared to less than 4% of DIMMs in Platform C and D. ... About a third of all machines in the fleet experience at least one memory error per year (see column CE Incid. %) and the average number of correctable errors per year is over 22,000. "
  - keldaris 9y ago
    As I understand it, the situation is even better (as in, less errors) than that with DDR4. Unfortunately, all the published data I could find is woefully out of date. Still, even if you generously assume something on the order of one correctable memory error per machine year, how many of those errors do you actually care about? Unless you have 100% memory utilization for 24/7 critical tasks, most of those errors probably don't even matter. EDIT: the least out of date reference I could find is a blog post by Jeff Atwood, where he concludes that based on the available literature ECC-correctable errors are quite rare. [1] [1] https://blog.codinghorror.com/to-ecc-or-not-to-ecc/ https://blog.codinghorror.com/to-ecc-or-not-to-ecc/

sillysaurus3 9y ago

Many physics simulations include internal checks (that must be there regardless of ECC, for algorithmic reasons) that would catch virtually all such issues. Hmm, like what? I've run many simulations too and had the opposite experience. It's hard to implement checks because your algorithm defines how the simulation should permute over time. While a bit error could certainly crash the simulation, long running simulations can be resumed from checkpoints with minimal loss of time and the probability of a crash is still very low for most real workloads. Not really. Your algorithm determines how the simulation plays out, so you can't really notice small errors until much later. By then it's hard to roll back to an earlier state unless you're saving 64GB snapshots.

twic 9y ago
I don't know about checks, but any algorithm which works by iteratively converging on a solution, like Newton-Raphson and its bigger relatives, has quite a lot of bit-error tolerance built in.
- keldaris 9y ago
  That's right, any iterative solver method (which already encompasses most of the low level numerical solvers used in physics today) or, more generally, any method that algorithmically guarantees satisfying a particular mathematical constraint after each timestep (say, if you're enforcing fluid incompressibility at each timestep, most* single bitflips will not cause errors that would accumulate over time), etc. [*] There are exceptions in specific circumstances most of which would produce obviously wrong results or crash the simulation outright. However, I'm not claiming that single bitflips are never an issue for simulations, only that it happens much less often than people sometimes think.
  - sillysaurus3 9y ago
    If a one-bit error causes the sign bit to flip, your position can go from 129,121.34 to -129,121.34. Obviously this is rare, but it seems mistaken to say that the simulation's parameters can prevent errors arising from this. Also, it's not just physics simulations that are at risk. Voxel renderings are especially susceptible to one-bit errors.