更常见的情况是，噪声会破坏数据。校验和可以在很多层面上解决这个问题;在数据线中，通常有一个奇偶校验位与数据一起传输。这大大降低了腐败的可能性。然后在解析级别上，无意义的数据通常会被忽略，因此即使某些损坏确实通过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。

此外，一些组件被电屏蔽以屏蔽噪音(我猜可能不是宇宙射线)。

但最后，正如其他回答者所说，偶尔会有位或字节被打乱，这取决于它是否是有效字节。最好的情况是，宇宙射线扰乱了其中一个空比特，完全没有影响，或者使计算机崩溃(这是一件好事，因为计算机避免了伤害);但最坏的情况，我相信你可以想象。

我经历过这种情况——宇宙射线翻转一点并不罕见，但一个人观察到这种情况的可能性很小。

2004年，我正在为一个安装程序开发一个压缩工具。我的测试数据是一些Adobe安装文件，压缩了大约500 MB或更多。

在冗长的压缩运行和解压运行以测试完整性之后，FC /B显示一个字节不同。

在这一个字节内，MSB翻转了。 我也急了，担心我有一个疯狂的bug，它只会在非常特定的条件下出现——我甚至不知道从哪里开始寻找。

但有声音让我再做一次测试。我运行它，它通过了。我设置了一个脚本，在一夜之间运行测试5次。到了早上，5个都已经过去了。

所以这绝对是宇宙射线位翻转。

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

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

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

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

更常见的情况是，噪声会破坏数据。校验和可以在很多层面上解决这个问题;在数据线中，通常有一个奇偶校验位与数据一起传输。这大大降低了腐败的可能性。然后在解析级别上，无意义的数据通常会被忽略，因此即使某些损坏确实通过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。

此外，一些组件被电屏蔽以屏蔽噪音(我猜可能不是宇宙射线)。

但最后，正如其他回答者所说，偶尔会有位或字节被打乱，这取决于它是否是有效字节。最好的情况是，宇宙射线扰乱了其中一个空比特，完全没有影响，或者使计算机崩溃(这是一件好事，因为计算机避免了伤害);但最坏的情况，我相信你可以想象。

使用ECC，您可以纠正宇宙射线的1位错误。为了避免10%的宇宙射线导致2位错误的情况，ECC细胞通常交错在芯片上，因此没有两个细胞彼此相邻。因此，影响两个单元格的宇宙射线事件将导致两个可纠正的1bit误差。

孙声明:(2002年4月第816-5053-10部分)

一般来说，宇宙射线软误差发生在DRAM存储器中 速率~10到100 FIT/MB (1 FIT = 1个设备故障在10亿小时)。 因此，具有10gb内存的系统应该每1000次显示一次ECC事件 到10,000小时，100gb的系统将显示一个事件 100到1000小时。然而，这只是一个粗略的估计 变化是上述效应的函数。