logo标签列表

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

statisticsphysicsprobabilityerror-detectionrisk-analysis
593

我又参加了一次设计评审会，听到有人声称特定情景发生的概率“比宇宙射线影响该程序的风险还要低”，这时我意识到自己对这个概率毫无头绪。

“因为2-128是340282366920938463463374607431768211456中的1，即使这些计算错误数十亿倍，我认为我们冒险一试也是有道理的...我相信我们更容易被宇宙射线打乱。”

这位程序员说得对吗？宇宙射线命中计算机并影响程序执行的概率是多少？

49
中奖彩票：它们对程序产生影响的概率是多少？ - kennytm
31
这部分取决于程序执行的地点和屏蔽效果。在地球上，宇宙射线通量比深空或近地轨道低得多。例如，哈勃太空望远镜产生的原始图像充满了宇宙射线迹象。 - Adam Hollidge
95
这是否意味着从现在开始，当有人询问finally块时，我们将不得不用“总是会执行除非程序退出，或者被宇宙射线击中”来说明？ - skaffman
77
数年前，我在开发一个粒子探测器的原型时，编程使其在被宇宙射线击中时打印“哎呀！”。那时感觉真是美妙的时光…… - Beta
9
我读到这里最有趣的问题之一。真正开了我的眼界。请相信我会重新打开这个问题。 - Agnel Kurian
显示剩余23条评论
15个回答
324

来自维基百科：

  

IBM在1990年代的研究表明，计算机通常每256兆字节的内存每月会发生约一个宇宙射线诱导错误。[15]

这意味着每个字节每月有3.7 × 10-9的故障概率，即每个字节每秒有1.4 × 10-15的故障概率。如果您的程序运行1分钟并占用20 MB的内存，则故障概率将为

                 60 × 20 × 1024²
1 - (1 - 1.4e-15)                = 1.8e-6 a.k.a. "5 nines"

错误检查可以帮助减少故障的影响。 此外，正如Joe所评论的，由于芯片尺寸更加紧凑，失败率可能与20年前不同。

15
更重要的是，1995年CPU芯片的特征尺寸约为0.35微米或350纳米。现在它的尺寸缩小到了原来的1/10，即35纳米。 - Joe Koberg
27
减小规模有可能增加风险吗？因为改变每个位的状态所需的能量更少了。 - Robert
71
减小尺寸肯定会增加风险。太空器的硬化处理器采用非常大的特征尺寸，以避免宇宙射线的影响。 - Joe Koberg
26
不仅是宇宙射线，芯片材料中的放射性同位素才是更大的问题。制造商会付出巨大的努力确保硅、焊料、封装等不含任何α或β辐射物质。 - Martin Beckett
19
哇！这意味着我的电脑每两天就会出现大约1个字节的损坏。 - Stefan Monov
显示剩余12条评论
98

显然，它是相当重要的。根据这篇新科学家文章中引用英特尔专利申请的话：

"宇宙射线诱发的计算机崩溃已经发生，并随着芯片上器件（例如晶体管）缩小而预计会频繁发生。这个问题被预计在未来十年成为计算机可靠性的主要限制因素。"

您可以在此处查看完整的专利内容。

9
为什么芯片尺寸越小，错误率就越高？毕竟，较小的物体被射线击中的可能性较小（例如将网球撞向墙壁与将其撞向邮票进行比较）。 - Jonathan.
14
随着元件尺寸的缩小，它们变得更加敏感于宇宙射线的影响。 - ire_and_curses
7
大小越小，被击中的可能性就越小，但被击中后影响状态的可能性就更大。 - John Hascall
2
@ire_and_curses 【需要引用】 - Anko
13
作为元器件尺寸变小，设置一个位所需的电压和电荷会减少，因此它更容易受到来自外层空间的能量干扰。这使得它更加敏感。这里有一段引文可供参考：随着LSI存储器件变得越来越小，它们对核辐射诱导的软失效也变得更加敏感。链接如下：As LSI memory devices become smaller, they become more sensitive to nuclear-radiation-induced soft fails. - ire_and_curses
显示剩余3条评论
72
注意：本答案不涉及物理问题，而是关于非ECC内存模块的静默内存错误。一些错误可能来自外太空，一些错误则来自台式机的内部空间。 有几项关于大型服务器群（如CERN集群和Google数据中心）上ECC内存故障的研究。具有ECC的服务器级硬件可以检测和纠正所有单比特错误，并检测许多多比特错误。
我们可以假设有很多非ECC台式机（和非ECC移动智能手机）。如果我们查看ECC可纠正错误率（单比特翻转）的论文，我们就可以知道非ECC内存上的静默内存损坏率。

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

  • 2009年Google论文“野外DRAM错误”指出，每Mb可能会有25000-75000个一位FIT（每十亿小时故障时间），这相当于经过我的计算，每8GB RAM每小时1-5个位错误。该论文也提到了同样的内容：“每GB每年平均可纠正错误率为2000-6000”。

  • 2012年Sandia报告“大规模高性能计算中静默数据损坏的检测和纠正”：虽然“双位翻转被认为不太可能”，但在ORNL密集的Cray XT5上，即使使用ECC，它们的“75,000+ DIMMs每天会出现一个”错误。而单位错误应该更高。

所以，如果程序具有大量数据集（数GB），或具有较高的内存读写速率（GB/s或更高），并且运行时间长达数小时，则我们可以期望桌面硬件会出现数个静默位翻转。这种速率无法通过memtest检测，DRAM模块是好的。

在数千台非ECC PC上进行长时间集群运行，例如BOINC全球范围内的网格计算，将始终存在来自内存位翻转以及磁盘和网络静默错误的错误。

对于更大的机器（数万台服务器），即使拥有单比特错误的ECC保护，正如我们在Sandia 2012年的报告中看到的那样，每天可能会有双位翻转，因此您将没有机会运行数天的完整并行程序（除非定期进行检查点并从最近的良好检查点重新启动以防止双重错误）。巨型机器的缓存和CPU寄存器（包括架构和内部芯片触发器，例如ALU数据通路）也会出现位翻转，因为其中并非所有部分都受到ECC保护。

提示：如果DRAM模块出现问题，情况会更加糟糕。例如，我曾经在笔记本电脑中安装了新的DRAM，几周后电脑就死机了。它开始出现大量的内存错误。我的电脑会卡住、Linux重新启动、运行fsck，在根文件系统上发现错误，并表示希望在纠正错误后重新启动。但是在每次下一次重启（我做了约5-6次）时，仍然会在根文件系统上发现错误。

12
来自 BH 2011 的附加材料：“Bitsquatting. DNS hijacking without exploitation” https://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinaburg_Bitsquatting_WP.pdf 列出现代多GB DRAM的FIT / Mbit约为10000-30000（每128MB的错误间隔不到100小时）。该论文还列出了一些文章，结论是大多数软错误来自辐射，几乎所有情况都来自宇宙射线，一些情况来自PC内部的阿尔法放射性物质。 BH作者进行了实验，并从流行网站中更改了1位，获得了50000次访问。 - osgx
感谢您在这里添加更多最新的研究。鉴于SO投票的动态性以及它们随时间累积的方式，很遗憾很难让这个主题的最新演示脱颖而出（在这里）。 - Fizz
我们曾经遇到过类似的问题。虽然我们没有进行详细的研究，但是我们有很多可见位翻转的崩溃转储。我们检查了这些位翻转，结果发现它们在代码段中。我们将其与应该存在的内容进行比较，发现它们不像是故意修改（即生成的指令没有太多意义）。 最后，我们开发了一个简单的应用程序，将崩溃转储与（存档的）发布版本进行比较，并过滤出这种情况。 有趣的是，我认为大多数这样的情况都来自伊朗、阿拉伯和南美洲的一个国家（现在记不清了）。 - GiM
2
在谷歌的论文中，看起来更像是一些RAM出了问题。我们机器群中约有三分之一的机器和超过8%的DIMM每年至少会出现一个可纠正错误。我们每个DIMM的可纠正错误率相当于每Mbit 25,000-75,000 FIT（每十亿小时操作时间内的故障次数），中位数FIT范围为778-25,000每Mbit（带有错误的DIMM的中位数），而以前的研究报告200-5,000 FIT每Mbit。每个DIMM的可纠正错误数量是高度变化的，有些DIMM与其他DIMM相比会经历大量错误。 - vartec
哎呀！这个答案中已经有很多位错误了：“每百万比特一个FIT”，“Corruptionfor”。 - TeaDrinker
31

维基百科引用了IBM的一项研究, 该研究于90年代指出："每256兆字节的内存每月通常会发生约一个因宇宙射线引起的错误。"不幸的是，引文是来自《科学美国人》杂志，没有提供进一步的参考资料。个人认为这个数字非常高，但也许大多数由宇宙射线引起的内存错误并不会导致实际或可察觉的问题。

另一方面，当涉及到软件场景的概率时，人们通常对自己所说的内容一无所知。

7
一个比特翻转的概率必须乘以这个比特对程序产生显著影响的概率。我猜测第二个概率比你想象的要低得多。 - Mark Ransom
76
是的，但是大多数的内存都包含数据，其中翻转不会那么明显。 - zoul
2
@Robert Harvey，大部分程序不仅是数据，而且实际上很多程序很少甚至从未执行过。想想测试覆盖率达到100%有多难。此外，一些指令变化可能非常微妙。将所有这些结合起来，概率开始变得非常低。 - Mark Ransom
35
@zoul. 笑"visiblp" 的时候，如果 e=1100101，p=1110000，那么你不幸地成为了 3 个比特位翻转的受害者！ - PaulG
11
@Paul：或者 一个 手指按下。 - mpen
显示剩余4条评论
31
24
联邦监管机构正在研究丰田车突然加速是否与宇宙射线有关。这就是为什么你不应该让联邦监管机构掌控你的生活的原因。 - user1228
13
我猜测这里的理论是，宇宙射线会翻转老年人大脑中的比特位，导致它们失灵并按下错误的踏板。 - Knox
17
“显然”？我认为这个观点目前算是一个猜测。我自己的猜测是，这种现象可能是嵌入式系统（实际上是大多数复杂的计算机系统）最古老的噩梦——竞态条件所导致的结果。 - Michael Burr
8
@Knox: 拿出你的旧锡箔帽，它确实有用！ - Roger Pate
3
可能并不是个笑话，我以前见过一些非常奇怪的事情发生过。这种情况并不像大多数人想象的那样罕见。 - Brian Knoblauch
显示剩余4条评论
28

通过采用ECC技术，可以纠正宇宙射线引起的1位误差。为了避免宇宙射线导致的2位误差的10%情况，ECC单元通常交错分布在芯片上，以便没有两个单元相邻。宇宙射线事件影响两个单元将产生两个可纠正的1位错误。

Sun公司表示：（Part No. 816-5053-10 April 2002）

一般来说，在DRAM存储器中，宇宙射线软错误发生率约为每MB的 FIT（1 FIT = 10亿小时内出现1次设备故障）范围在10到100之间。因此，具有10 GB内存的系统应该每1,000至10,000小时出现一次ECC事件，而具有100 GB的系统则会每100至1,000小时出现一次事件。但这只是一个粗略的估计值，会受到上述影响因素的影响而变化。

18
记忆错误是真实存在的，ECC内存确实有所帮助。正确实现的ECC内存将纠正单个位错误并检测双位错误（如果检测到此类错误，则会停止系统）。您可以从人们经常抱怨似乎是软件问题，但通过运行Memtest86并发现坏内存得到解决来看出这一点。当然，宇宙射线引起的瞬态故障与持续失败的内存不同，但对于更广泛的问题——您应该多少信任内存以正确运行——这是相关的。
基于20 MB驻留大小的分析可能适用于微不足道的应用程序，但大型系统通常具有具有大型主内存的多个服务器。
有趣的链接：http://cr.yp.to/hardware/ecc.html 页面上的Corsair链接不幸地似乎已失效，因此请在此处查看Corsair链接。
宇宙射线位翻转可能不是均匀分布的，特别是如果我们将太阳风暴纳入“宇宙射线事件”范畴。如果在同一个字节中发生两个或更多位翻转，则典型的ECC将无法纠正错误。 - tobixen
@tobixen 检测双位错误比继续使用错误数据更好。ECC之后的下一步是使用DIMM镜像的Chipkill技术... - janm
16

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

例如，注意到专为“嵌入式”应用程序设计的英特尔产品往往会在规格说明中添加ECC。而针对平板电脑的Bay Trail则没有它，因为这会使内存变得更加昂贵，可能还会更慢。如果平板电脑偶尔崩溃一次程序，用户并不太关心。相比较，软件本身要比硬件不可靠得多。但是对于用于工业机械和汽车的SKU，ECC是强制性的。因为在这里，我们期望软件更加可靠，并且来自随机干扰的错误将是一个真正的问题。

符合IEC 61508和类似标准的系统通常具有引导测试，检查所有RAM是否功能正常（无位卡在零或一），以及运行时的错误处理，尝试从ECC检测到的错误中恢复，并经常进行内存清洗任务，连续读写内存以确保注意到任何错误。

但对于主流PC软件来说，这不是个大问题。对于长寿命的服务器？使用ECC和故障处理器。如果一个无法纠正的错误导致内核崩溃，那就这样吧。或者你可以变得有点偏执，在使用锁步执行的冗余系统中，如果一个核心被损坏，另一个核心可以接管，同时第一个核心重新启动。

宇宙射线位翻转可能不是均匀分布的，特别是如果我们将太阳风暴包括在“宇宙射线事件”的范围内。突然的爆发可能会导致一个字节内出现多个位翻转，并且ECC算法将无法纠正故障。 - tobixen
13
如果一个程序是生命关键的（如果它失败会导致某人死亡），那么它需要以这样一种方式编写，即它要么具有故障安全功能，要么可以自动从这种故障中恢复。所有其他程序则因情况而异。
丰田汽车就是一个典型例子。不管你对油门电缆有什么看法，但它并不是软件。
另请参见http://en.wikipedia.org/wiki/Therac-25
别担心油门软件的问题。油门的传感器和线路是薄弱点。我的三菱油门位置传感器变成了一个随机数生成器...没有意外的加速，但对燃油混合物一点好处也没有！ - Brian Knoblauch
3
@Brian：好的软件应该能够发现数据点不连续，并得出数据不完整的结论。 - Robert Harvey
...然后呢...需要好的数据。知道数据不好也没有帮助。这不是你可以神奇地解决的问题。 - Brian Knoblauch
4
@Brian：首先，你可以根据数据不准确的事实采取纠正措施。例如，你可以停止加速。 - Robert Harvey
是的，您可以（而且应该）对数据进行校验和。最好的方法是端到端。然而，这只能减少损坏的可能性。想象一下，在您想要跳转到错误处理程序时，如果“是否有效”指令在内存或CPU寄存器中的位被损坏，会发生什么。 - eckes
12
"宇宙射线事件"在许多答案中被认为具有均匀分布，但这并不总是正确的（例如超新星）。虽然根据维基百科的定义，“宇宙射线”来自于外层空间，但我认为也可以将“局部”太阳风暴（又称日冕物质抛射）归为同一范畴。我相信它可能会在短时间内导致几个比特翻转，甚至足以破坏启用ECC的内存。
众所周知，太阳风暴可能会对电力系统造成很大的影响（例如1989年3月的魁北克停电事件）。计算机系统也很可能受到影响。"
大约10年前，我坐在另一个人旁边，我们各自使用笔记本电脑。当时太阳活动比较“狂暴”，我们身处北极，可以间接地观察到这一点——有很多极光可以看到。突然，在同一瞬间，我们的笔记本电脑都崩溃了。他使用的是OS X系统，我使用的是Linux系统。我们都不习惯笔记本电脑崩溃——在Linux和OS X系统上，这是相当罕见的事情。由于我们使用的是不同的操作系统，并且这并没有发生在闰秒期间，因此可以排除常见的软件错误。我认为那个事件是由“宇宙辐射”引起的。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接