我再一次进行了设计评审，并且遇到了一个声称特定情景的概率“低于宇宙射线的风险”影响该程序的说法，并且我发现我没有最微弱的想法是什么概率。
“由于2 -128 是340282366920938463463374607431768211456中的1，我认为我们有理由抓住这里的机会，即使这些计算已经减少了几十亿......我们我相信，宇宙射线的风险更大，我相信。“
这个程序员是否正确？ 宇宙射线撞击计算机并影响程序执行的概率是多少？
答案 0 :(得分：291)
来自Wikipedia：
IBM在20世纪90年代的研究表明，计算机通常每月每256兆字节RAM会遇到一次宇宙射线引起的错误。 [15]
这意味着每个字节每月3.7×10 -9 的概率，或每秒每秒1.4×10 -15 的概率。如果你的程序运行1分钟并占用20 MB的RAM，则失败概率为
60 × 20 × 1024²
1 - (1 - 1.4e-15) = 1.8e-6 a.k.a. "5 nines"
错误检查有助于减少失败的后果。此外，由于Joe评论的芯片尺寸更紧凑，故障率可能与20年前不同。
答案 1 :(得分：85)
显然，并非无足轻重。来自this New Scientist article，来自英特尔专利申请的引用：
“随着设备（例如，晶体管）芯片尺寸的减小，宇宙射线诱发的计算机崩溃已经发生并且预计随着频率的增加而增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”
您可以阅读full patent here。
答案 2 :(得分：46)
注意：这个答案不是关于物理，而是关于非ECC内存模块的静默内存错误。有些错误可能来自外太空，有些则来自桌面的内部空间。
在CERN集群和Google数据中心等大型服务器场上，有几项关于ECC内存故障的研究。具有ECC的服务器级硬件可以检测并纠正所有单个位错误，并检测许多多位错误。
我们可以假设有很多非ECC桌面（和非ECC移动智能手机）。如果我们检查文件的ECC纠正错误率（单位翻转），我们就可以知道非ECC内存上的静默内存损坏率。
Large scale CERN 2007 study "Data integrity"：供应商为其内存模块宣布＆＃34; 误码率为10 -12 ＆＃34;，＆＃ 34; 观察到的错误率比预期的低4个数量＆＃34;。对于数据密集型任务（8 GB / s的内存读取），这意味着可以每分钟（10 -12 供应商BER）或两天一次（10 -16）发生单比特翻转 BER）。
2009年Google的论文"DRAM Errors in the Wild: A Large-Scale Field Study"表示每Mbit最多可以有25000-75000个一位FIT（每十亿小时的失败次数），在我计算之后，对于8GB的RAM，这等于每小时1-5比特的错误。论文说的相同：＆＃34; 意味着每年每GB 2000-6000的可纠正错误率＆＃34;
2012 Sandia报告"Detection and Correction of Silent Data Corruptionfor Large-Scale High-Performance Computing"：＆＃34;双位翻转被认为不太可能＆＃34;但是在ORNL的密集Cray XT5中，它们的速度是每天一次，75,000 + DIMM＆＃34;即使有ECC。并且单比特错误应该更高。
因此，如果程序具有大型数据集（几GB），或者具有高内存读取或写入速率（GB / s或更高），并且运行了几个小时，那么我们可以预期多达几个静默位翻转桌面硬件。 memtest无法检测到这个速率，而DRAM模块也很好。
长群集在数千台非ECC PC上运行，如BOINC互联网范围的网格计算将始终存在来自内存位翻转以及磁盘和网络无声错误的错误。
对于更大的机器（10万台服务器），即使是针对单比特错误的ECC保护，正如我们在Sandia的2012年报告中看到的那样，每天都会有双位翻转，所以你没有几天运行全尺寸并行程序的机会（如果出现双重错误，无需定期检查点并从上一个好的检查点重新启动）。巨大的机器也会在其缓存和cpu寄存器（架构和内部芯片的触发器，例如ALU数据路径）中进行位翻转，因为并非所有这些都受ECC保护。
PS：如果DRAM模块坏了，情况会更糟。例如，我在笔记本电脑上安装了新的DRAM，几周后就死了。它开始产生很多内存错误。我得到的：笔记本电脑挂起，Linux重新启动，运行fsck，发现根文件系统上的错误，并表示它想在纠正错误后重新启动。但是在每次下次重启时（我做了大约5-6次），根文件系统上仍然存在错误。答案 3 :(得分：30)
Wikipedia引用了90年代的study by IBM，表明“计算机通常每月每256兆字节RAM会出现一次宇宙射线引起的错误。”不幸的是，引用的是科学美国人的一篇文章，该文章没有给出任何进一步的参考。就个人而言，我发现这个数字非常高，但也许宇宙射线引起的大多数记忆错误都不会引起任何实际或明显的问题。
另一方面，人们谈到软件场景的可能性时，通常不知道他们在谈论什么。
答案 4 :(得分：29)
嗯，宇宙射线显然导致丰田汽车中的电子设备发生故障，所以我会说概率非常高：）
答案 5 :(得分：23)
使用ECC，您可以纠正Cosmic Rays的1位错误。为了避免宇宙射线导致2位错误的10％的情况，ECC单元通常在芯片上交错，因此没有两个单元彼此相邻。因此，影响两个单元的宇宙射线事件将导致两个可纠正的1位误差。
Sun指出:( 2002年4月816-5053-10号部分）
一般来说，宇宙射线软错误发生在DRAM存储器中 速率~10到100 FIT / MB（1 FIT = 1个设备在10亿小时内失败）。 因此，具有10 GB内存的系统应该每1,000个显示一次ECC事件 到10,000小时，100 GB的系统每次都会显示一个事件 100至1,000小时。但是，这是一个粗略的估计 作为上述效果的函数而变化。
答案 6 :(得分：17)
内存错误是真实的，ECC内存确实有帮助。正确实现的ECC内存将纠正单个位错误并检测双位错误（如果检测到这样的错误，则暂停系统。）您可以通过运行{{{}来定期查看通常情况下人们抱怨的软件问题。 3}}并发现不良记忆。当然，由宇宙射线引起的瞬态失效与一直失败的记忆不同，但它与更广泛的问题有关，即你应该相信你的记忆能够正常运作。
基于20 MB常驻大小的分析可能适用于普通应用程序，但大型系统通常具有多个具有大型主存储器的服务器。
有趣的链接：Memtest86
遗憾的是，页面中的Corsair链接似乎已经死了。
答案 7 :(得分：13)
如果一个程序对生命至关重要（如果某个程序失败就会杀死它），它需要以一种故障安全方式编写，或者从这种故障中自动恢复。所有其他程序，YMMV。
丰田汽车就是一个很好的例子。说出你对油门电缆的看法，但它是不是软件。
答案 8 :(得分：12)
这是一个真正的问题，这就是ECC内存用于服务器和嵌入式系统的原因。为什么飞行系统不同于地面飞行系统。
例如，请注意英特尔部件的目的地为＆＃34; embedded＆＃34;应用程序倾向于将ECC添加到规格表中。平板电脑的Bay Trail缺乏它，因为它会使内存更昂贵并且可能更慢。如果平板电脑每次在蓝色月亮中崩溃一个程序，用户就不会太在意了。无论如何，软件本身远不如硬件可靠。但对于打算用于工业机械和汽车的SKU，ECC是强制性的。从这里开始，我们期望SW更可靠，随机扰动的错误将是一个真正的问题。
符合IEC 61508和类似标准的系统通常都有启动测试，可以检查所有RAM是否正常工作（没有位卡在零或一个位置），以及运行时尝试从检测到的错误中恢复的错误处理ECC，通常还有内存擦除器任务，它们可以连续读取和写入内存，以确保发生的任何错误都会被注意到。
但对于主流PC软件？没有大碍。对于长寿命的服务器？使用ECC和错误处理程序。如果无法纠正的错误导致内核崩溃，那就这样吧。或者你变得偏执并使用具有锁定步骤执行的冗余系统，这样如果一个核心被破坏，另一个核心可以在第一个核心重新启动时接管。
答案 9 :(得分：11)
我曾编程过要在太空中飞行的设备，然后你（据说，没有人向我展示任何关于它的论文，但据说这是业务中的常识）可能会期望宇宙射线会导致所有的错误时间。
答案 10 :(得分：8)
众所周知，太阳风暴会对电力系统造成相当大的破坏（如Quebec power outage in March 1989）。计算机系统很可能也会受到影响。
大约10年前，我坐在另一个人的旁边，我们坐在我们的每台笔记本电脑上，这是一个充满“暴风雨”太阳天气的时期（坐在北极，我们可以间接地观察到这一点 - 很多北极光（Aurora borealis）。突然 - 在同一时刻 - 我们的笔记本电脑都崩溃了。他正在运行OS X，我正在运行Linux。我们都不习惯笔记本电脑崩溃 - 这在Linux和OS X上是一件非常罕见的事情。由于我们在不同的操作系统上运行，所以可以或多或少地排除常见的软件错误（并且它在飞跃过程中没有发生过第二）。我把这个事件归结为“宇宙辐射”。
后来，“宇宙辐射”已成为我工作场所的一个内部笑话。每当我们的服务器出现问题而我们找不到任何解释时，我们开玩笑地将故障归结为“宇宙辐射”。 ： - ）
答案 11 :(得分：7)
更常见的是，噪音可能会破坏数据。 Checksums用于在许多层面上对抗这种情况;在数据线中，通常有parity bit与数据一起传播。这极大降低了腐败的可能性。然后在解析级别时，通常忽略无意义数据，因此即使某些损坏确实超过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。
另外，有些组件electrically shielded可以阻挡噪音（我猜可能不是宇宙射线）。
但是最后，正如其他的回答者所说的那样，偶尔会有一些比特或字节被扰乱，并且无论这是否是一个重要字节，都有可能。最好的情况是，一个宇宙射线扰乱其中一个空位并且完全没有效果，或者使计算机崩溃（这是一件好事，因为计算机不会受到伤害）;但最坏的情况是，我相信你可以想象。
答案 12 :(得分：5)
我已经经历过这一点 - 宇宙射线翻转一点并不罕见，但是一个人观察它的可能性很小。
我在2004年为安装程序开发了一个压缩工具。我的测试数据是一些大约500 MB或更多解压缩的Adobe安装文件。
经过繁琐的压缩运行和解压缩运行以测试完整性后，FC / B显示一个字节不同。
在那一个字节内，MSB已翻转。 我也翻了个身，担心我有一个只会在非常特殊的情况下出现的疯狂错误 - 我甚至不知道从哪里开始寻找。
但有些事告诉我再次进行测试。我跑了它，它通过了。我设置了一个脚本，在一夜之间运行测试5次。所有5人早上都过去了。
所以这绝对是一个宇宙射线位翻转。
答案 13 :(得分：4)
您可能也希望了解容错硬件。
例如，Stratus Technology构建名为ftServer的Wintel服务器，它在锁定步骤中具有2或3个“主板”，比较计算结果。 （这也有时在太空飞行器上完成）。
Stratus服务器从定制芯片组演变为背板上的锁步。
一个非常相似（但软件）的系统是基于Hypervisor的VMWare Fault Tolerance锁步。
答案 14 :(得分：3)
作为一个数据点，这恰好发生在我们的构建中：
02:13:00,465 WARN - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN - ^
02:13:00,465 WARN - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN - ^
这看起来非常像在编译期间发生翻转，在源文件中非常重要的位置。
我不一定说这是“宇宙射线”，但症状是匹配的。