注意:这个答案不是关于物理的，而是关于非ecc内存模块的无声内存错误。有些错误可能来自外部空间，有些则来自桌面内部空间。

在大型服务器场(如CERN集群和谷歌数据中心)上有几项关于ECC内存故障的研究。带有ECC的服务器级硬件可以检测和纠正所有的单比特错误，并检测许多多比特错误。

我们可以假设有很多非ecc台式机(以及非ecc移动智能手机)。如果我们检查论文的ecc可纠正错误率(单位翻转)，我们可以知道非ecc内存上的静默内存损坏率。

Large scale CERN 2007 study "Data integrity": vendors declares "Bit Error Rate of 10-12 for their memory modules", "a observed error rate is 4 orders of magnitude lower than expected". For data-intensive tasks (8 GB/s of memory reading) this means that single bit flip may occur every minute (10-12 vendors BER) or once in two days (10-16 BER). 2009 Google's paper "DRAM Errors in the Wild: A Large-Scale Field Study" says that there can be up to 25000-75000 one-bit FIT per Mbit (failures in time per billion hours), which is equal to 1 - 5 bit errors per hour for 8GB of RAM after my calculations. Paper says the same: "mean correctable error rates of 2000–6000 per GB per year". 2012 Sandia report "Detection and Correction of Silent Data Corruptionfor Large-Scale High-Performance Computing": "double bit flips were deemed unlikely" but at ORNL's dense Cray XT5 they are "at a rate of one per day for 75,000+ DIMMs" even with ECC. And single-bit errors should be higher.

因此，如果程序有很大的数据集(几GB)，或者有很高的内存读写速率(GB/s或更高)，并且它运行了几个小时，那么我们可以期望在桌面硬件上进行几次静默位翻转。memtest检测不到这个速率，DRAM模块表现良好。

长集群在数千台非ecc pc上运行，比如BOINC，互联网范围的网格计算总是会有内存位翻转、磁盘和网络静默错误造成的错误。

And for bigger machines (10 thousands of servers) even with ECC protection from single-bit errors, as we see in Sandia's 2012 report, there can be double-bit flips every day, so you will have no chance to run full-size parallel program for several days (without regular checkpointing and restarting from last good checkpoint in case of double error). The huge machines will also get bit-flips in their caches and cpu registers (both architectural and internal chip's triggers e.g. in ALU datapath), because not all of them are protected by ECC.

PS:如果DRAM模块坏了，情况会更糟。例如，我在笔记本电脑上安装了新的DRAM，几周后它就死机了。它开始出现很多内存错误。我得到:笔记本电脑挂起，linux重启，运行fsck，在根文件系统上发现错误，并说它想在纠正错误后重新启动。但是在每次重新启动(我做了大约5-6次)时，仍然会在根文件系统上发现错误。

维基百科引用了IBM在90年代的一项研究，该研究表明“计算机通常每个月每256兆字节的RAM中会出现一次宇宙射线引起的错误。”不幸的是，引用的是《科学美国人》上的一篇文章，该文章没有提供任何进一步的参考文献。就我个人而言，我发现这个数字非常高，但也许大多数由宇宙射线引起的记忆错误不会引起任何实际或明显的问题。

另一方面，当涉及到软件场景时，人们谈论概率通常不知道他们在谈论什么。

注意:这个答案不是关于物理的，而是关于非ecc内存模块的无声内存错误。有些错误可能来自外部空间，有些则来自桌面内部空间。

在大型服务器场(如CERN集群和谷歌数据中心)上有几项关于ECC内存故障的研究。带有ECC的服务器级硬件可以检测和纠正所有的单比特错误，并检测许多多比特错误。

我们可以假设有很多非ecc台式机(以及非ecc移动智能手机)。如果我们检查论文的ecc可纠正错误率(单位翻转)，我们可以知道非ecc内存上的静默内存损坏率。

Large scale CERN 2007 study "Data integrity": vendors declares "Bit Error Rate of 10-12 for their memory modules", "a observed error rate is 4 orders of magnitude lower than expected". For data-intensive tasks (8 GB/s of memory reading) this means that single bit flip may occur every minute (10-12 vendors BER) or once in two days (10-16 BER). 2009 Google's paper "DRAM Errors in the Wild: A Large-Scale Field Study" says that there can be up to 25000-75000 one-bit FIT per Mbit (failures in time per billion hours), which is equal to 1 - 5 bit errors per hour for 8GB of RAM after my calculations. Paper says the same: "mean correctable error rates of 2000–6000 per GB per year". 2012 Sandia report "Detection and Correction of Silent Data Corruptionfor Large-Scale High-Performance Computing": "double bit flips were deemed unlikely" but at ORNL's dense Cray XT5 they are "at a rate of one per day for 75,000+ DIMMs" even with ECC. And single-bit errors should be higher.

因此，如果程序有很大的数据集(几GB)，或者有很高的内存读写速率(GB/s或更高)，并且它运行了几个小时，那么我们可以期望在桌面硬件上进行几次静默位翻转。memtest检测不到这个速率，DRAM模块表现良好。

长集群在数千台非ecc pc上运行，比如BOINC，互联网范围的网格计算总是会有内存位翻转、磁盘和网络静默错误造成的错误。

And for bigger machines (10 thousands of servers) even with ECC protection from single-bit errors, as we see in Sandia's 2012 report, there can be double-bit flips every day, so you will have no chance to run full-size parallel program for several days (without regular checkpointing and restarting from last good checkpoint in case of double error). The huge machines will also get bit-flips in their caches and cpu registers (both architectural and internal chip's triggers e.g. in ALU datapath), because not all of them are protected by ECC.

PS:如果DRAM模块坏了，情况会更糟。例如，我在笔记本电脑上安装了新的DRAM，几周后它就死机了。它开始出现很多内存错误。我得到:笔记本电脑挂起，linux重启，运行fsck，在根文件系统上发现错误，并说它想在纠正错误后重新启动。但是在每次重新启动(我做了大约5-6次)时，仍然会在根文件系统上发现错误。

这是一个真正的问题，这就是为什么在服务器和嵌入式系统中使用ECC内存。以及为什么飞行系统与地面系统不同。

For example, note that Intel parts destined for "embedded" applications tend to add ECC to the spec sheet. A Bay Trail for a tablet lacks it, since it would make the memory a bit more expensive and possibly slower. And if a tablet crashes a program every once in a blue moon, the user does not care much. The software itself is far less reliable than the HW anyway. But for SKUs intended for use in industrial machinery and automotive, ECC is mandatory. Since here, we expect the SW to be far more reliable, and errors from random upsets would be a real issue.

通过IEC 61508和类似标准认证的系统通常都有启动测试，检查所有RAM是否正常(没有位卡在0或1)，以及运行时的错误处理，试图从ECC检测到的错误中恢复，通常还有内存清除任务，不断地遍历和读写内存，以确保发生的任何错误都能被注意到。

但是对于主流PC软件来说呢?没什么大不了的。对于长期存在的服务器?使用ECC和故障处理程序。如果一个不可纠正的错误杀死了内核，那就这样吧。或者你偏执地使用带有锁步执行的冗余系统，这样如果一个核心损坏，另一个核心可以在第一个核心重新启动时接管。

好吧，显然是宇宙射线导致丰田汽车的电子设备出现故障，所以我想说这种可能性非常高:)

宇宙射线真的导致了丰田的灾难吗?

Memory errors are real, and ECC memory does help. Correctly implemented ECC memory will correct single bit errors and detect double bit errors (halting the system if such an error is detected.) You can see this from how regularly people complain about what seems to be a software problem that is resolved by running Memtest86 and discovering bad memory. Of course a transient failure caused by a cosmic ray is different to a consistently failing piece of memory, but it is relevant to the broader question of how much you should trust your memory to operate correctly.

基于20 MB常驻大小的分析可能适用于普通应用程序，但大型系统通常有多个具有较大主存的服务器。

有趣的链接:http://cr.yp.to/hardware/ecc.html

不幸的是，海盗链接在页面似乎死了，所以查看海盗链接在这里代替。