4 ms·
Another comment[1] mentioned 1 bitflip per gigabyte per month. If you have a lot of RAM, that's rather a lot. > It doesn't matter whether a bitflip (unlikely)
by dkersten 6y ago
Another comment[1] mentioned 1 bitflip per gigabyte per month. If you have a lot of RAM, that's rather a lot.
> It doesn't matter whether a bitflip (unlikely) or some bug (likely) causes a node to spuriously fail
Except that a bitflip can go undetected. It may crash your software or system, but it also may simply leak errors into your data, which can be far more catastrophic.
[1] https://news.ycombinator.com/item?id=25623206 https://news.ycombinator.com/item?id=25623206
- thequux 6y agoI have a server with 384GB of RAM sitting next to me, and in two months of uptime with the only shielding being a pile of IBM iron on top of it, it has detected a grand total of 0 errors. This is, of course, an anecdote rather than data, but 0 is different enough from the expected 768 that it makes me doubt that statistic.
- jhasse 6y agoSo can a bug.
- dkersten 6y agoYes. And? That doesn't suddenly make bitflips benign.
- incrudible 6y agoThe point is that you can't prevent failure by just buying something. You have to deal with the fact that failure can not be prevented. In other words, if a single defective DIMM somewhere in your deployment is causing catastraphic failure, your mistake was not buying the wrong RAM modules. Your mistake was relying on a single point of failure for mission critical data.
- hda2 6y agoPeople might not be preventing failure by using ECC, but they significantly decrease the likelihood of having to deal with hard-to-debug problems caused by bitflips.