宇宙射线：它们会影响程序的概率是多少？

我再一次进行设计审查，并遇到一种说法，即特定场景的可能性“小于宇宙射线的风险”对程序的影响，但我发现我并不了解那是什么。概率是。

“由于2 ^-128是340282366920938463463374374607431768211456中的1，因此我认为我们有理由在这里冒险，即使这些计算相差数十亿倍……我们更容易受到宇宙射线的威胁我相信，把我们搞砸了。”

这个程序员正确吗？宇宙射线撞击计算机并影响程序执行的概率是多少？

来自维基百科：

IBM在1990年代进行的研究表明，计算机通常每个月每256 MB 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年前。

显然，不是无关紧要的。在这篇《新科学家》文章中，引用了一项英特尔专利申请：

“宇宙射线引起的计算机崩溃已经发生，并且随着设备（例如晶体管）芯片尺寸的减小，频率会随着频率增加而增加。预计该问题将在未来十年成为计算机可靠性的主要限制因素。”

您可以在此处阅读完整的专利。

注意： 此答案与物理无关，而是与非ECC内存模块有关的静默内存错误。有些错误可能来自外部空间，有些则来自桌面的内部空间。

对大型服务器场（例如CERN群集和Google数据中心）上的ECC内存故障进行了多项研究。具有ECC的服务器级硬件可以检测和纠正所有单位错误，并且可以检测许多多位错误。

我们可以假设存在许多非ECC台式机（和非ECC移动智能手机）。如果我们检查文件中可纠正ECC的错误率（单个位翻转），则可以知道非ECC存储器上的静默存储器损坏率。

• CERN 2007大规模研究“数据完整性”：供应商宣称“ 其内存模块的误码率10 ^-12 ”，“ 观察到的误码率比预期的低4个数量级 ”。对于数据密集型任务（8 GB / s的内存读取），这意味着每分钟（10 ^-12个供应商BER）或两天一次（10 ^-16 BER）可能发生单位翻转。

• 2009年Google的论文“狂野的DRAM错误：大规模现场研究”指出，每Mbit最多可以有25000-75000个1位FIT（每十亿小时的时间故障），相当于1-5位经过我的计算，每小时出现8GB RAM的每小时错误。论文也这么说：“ 平均可纠正错误率是每年每GB 2000–6000 ”。

• 2012年桑迪亚报告“大规模高性能计算的静默数据损坏的检测和纠正”：“不太可能出现双位翻转”，但是在ORNL密集的Cray XT5中，它们“每天有75,000个以上DIMM的速度”与ECC。而且单位错误应该更高。

因此，如果程序具有大数据集（几个GB），或者具有很高的内存读写速率（GB / s或更高），并且运行了几个小时，那么我们可以预期台式机硬件上最多会出现几次静默翻转。memtest无法检测到此速率，并且DRAM模块良好。

长集群可以在数千台非ECC PC上运行，例如BOINC互联网范围内的网格计算将始终会由于内存位翻转以及磁盘和网络静默错误而产生错误。

对于更大的机器（上万台服务器），即使具有ECC保护免受单个位错误的影响，正如我们在Sandia 2012年的报告中所看到的那样，每天可能会有双位翻转，因此您将没有机会运行全尺寸并行程序运行几天（没有常规检查点，并在出现两次错误的情况下从上一个好的检查点重新启动）。大型计算机还将在其缓存和cpu寄存器（例如架构和内部芯片的触发器，例如在ALU数据路径中）中发生位翻转，因为并非所有计算机都受ECC保护。

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

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

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

好吧，宇宙射线显然导致了丰田汽车中的电子设备发生故障，所以我想说可能性很高：)

宇宙射线真的会引起丰田的麻烦吗？

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

太阳州：（零件号816-5053-10 2002年4月）

一般来说，宇宙射线软错误在DRAM内存中的发生速率约为10至100 FIT / MB（1 FIT = 1台设备在十亿小时内发生故障）。因此，具有10 GB内存的系统应该每1000到10,000小时显示一次ECC事件，而具有100 GB的系统将每100到1,000小时显示一次ECC事件。但是，这是一个粗略的估计，将随上述效应而变化。

内存错误是真实的，而ECC内存确实有帮助。正确实施的ECC内存将纠正单个位错误并检测到双位错误（如果检测到此类错误，则将系统暂停。）您可以从人们经常抱怨通过运行Memtest86和发现不好的记忆。当然，由宇宙射线引起的瞬态故障与持续发生故障的内存有所不同，但是它与更广泛的问题有关，即您应该信任内存以正确运行的程度。

基于20 MB驻留大小的分析可能适用于琐碎的应用程序，但是大型系统通常具有多台具有大型主内存的服务器。

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

不幸的是，页面中的Corsair链接似乎已消失。

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

例如，请注意，面向“嵌入式”应用程序的英特尔零件往往会将ECC添加到规格表中。平板电脑的Bay Trail缺少它，因为它会使内存贵一些，甚至可能更慢。而且，如果平板电脑每一次在蓝月亮中使程序崩溃一次，用户就不会在意。无论如何，软件本身的可靠性远不如硬件可靠。但是对于打算用于工业机械和汽车的SKU，ECC是强制性的。从这里开始，我们期望软件更加可靠，随机扰动带来的错误将是一个现实问题。

经过IEC 61508和类似标准认证的系统通常具有启动测试（该测试可检查所有RAM是否正常工作（没有位卡在零或一处）），以及在运行时尝试从ECC检测到的错误中恢复的错误处理，以及通常，内存清理程序任务会不断地进行读取和写入内存，以确保发现发生的任何错误。

但是对于主流PC软件呢？没有大碍。对于寿命长的服务器？使用ECC和故障处理程序。如果一个无法纠正的错误杀死了内核，那就去吧。否则，您会变得偏执，并使用具有锁定步骤执行功能的冗余系统，这样，如果一个内核损坏了，则另一个内核可以在第一个内核重新引导时接管。

如果程序是至关重要的程序（如果失败将杀死某人），则需要以某种方式编写该程序，使其既可以进行故障保护，又可以从这种故障中自动恢复。所有其他程序，YMMV。

丰田就是一个很好的例子。说说您对油门线的看法，但这不是软件。

另请参见http://en.wikipedia.org/wiki/Therac-25

我曾经为将要在太空中飞行的设备编程，然后您（据说，没人给我看过有关它的任何论文，但是据说这是商业上的常识）可以期望宇宙射线一直在引起错误。

在这里的许多答案中，“宇宙射线事件”被认为具有均匀的分布，这可能并不总是正确的（即超新星）。尽管“宇宙射线”的定义（至少根据维基百科而言）来自外太空，但我认为也包括局部太阳风暴（也就是在同一伞下的日冕物质抛射）是公平的。时间跨度短，可能足以破坏甚至启用ECC的内存。

众所周知，太阳风暴会给电力系统造成相当大的破坏（例如1989年3月的魁北克停电）。计算机系统也很有可能也会受到影响。

大约10年前，我正坐在另一个人旁边，我们每个笔记本电脑都坐在一起，当时正好是“暴风雨”的太阳天气（坐在北极，我们可以间接观察到这一点-很多北极光可见）。突然-在同一瞬间-我们的两台笔记本电脑都崩溃了。他正在运行OS X，而我正在运行Linux。我们俩都不习惯笔记本电脑崩溃的情况-在Linux和OS X上这是很少见的事情。由于我们在不同的OS上运行，因此可以或多或少地排除常见的软件错误（而且在飞跃期间并没有发生）第二）。我将这一事件归因于“宇宙辐射”。

后来，“宇宙辐射”成为我工作场所的一个内部笑话。每当我们的服务器发生任何事情而我们找不到任何解释时，我们开玩笑地将故障归因于“宇宙辐射”。:-)

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

而且，某些组件被电屏蔽以屏蔽噪声（我猜想可能不是宇宙射线）。

但是最后，就像其他答复者所说的那样，偶尔会有一些位或字节被打乱，这取决于是否是有效字节。最好的情况是，宇宙射线会扰乱其中一个空位，并且完全没有影响，或者使计算机崩溃（这是一件好事，因为计算机不会受到伤害）；但最坏的情况是，我敢肯定，你可以想象。

我已经经历了-宇宙射线翻转一点并不罕见，但是人们很难观察到这一点。

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

经过繁琐的压缩运行和解压缩运行以测试完整性之后，FC / B显示一个字节的差异。

MSB已在该字节内翻转。我也翻了个身，担心我有一个疯狂的错误，该错误只会在非常特定的条件下才会出现-我什至不知道从哪里开始寻找。

但是有件事告诉我要再次运行测试。我运行它并通过了。我设置了一个脚本来在一夜之间运行测试5次。早晨，所有五个人都过去了。

所以那绝对是宇宙射线的翻转。

您可能还想看看容错硬件。

例如，Stratus Technology建造了名为ftServer的Wintel服务器，该服务器具有两个或三个锁定步骤的“主板”，比较了计算结果。（有时在航天器中也是如此）。

Stratus服务器从定制芯片组发展到背板上的锁相环。

一个非常相似（但为软件）的系统是基于Hypervisor的VMWare Fault Tolerance锁定步骤。

作为数据点，这只是在我们的构建中发生的：

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  - ^

这看起来非常像是在编译过程中发生的一些翻转，偶然地在源文件中的非常重要的位置。

我并不一定要说这是“宇宙射线”，但症状是一致的。