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

小开

最佳答案

从# EYZ0:

IBM在20世纪90年代的研究表明，计算机通常每个月每256兆字节的RAM会经历一次宇宙射线引起的错误

这意味着概率为3.7 &倍;每个字节每月10⁹，或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年前不同。

小开

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

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

小开

显然，这并非微不足道。来自这篇《新科学家》文章，引用自英特尔专利申请:

“宇宙射线引发的电脑死机已经发生过，而且随着芯片中器件(例如晶体管)尺寸的减小，预计死机的频率将会增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”

你可以阅读完全专利。

小开

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

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

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

小开

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

宇宙射线真的造成了丰田的灾难吗?< / >

小开

我曾经为在太空中飞行的设备编程，然后你(据说，没有人给我看过任何关于这方面的论文，但据说这是业内的常识)可以预期宇宙射线总是会导致错误。

小开

如果一个程序是生命攸关的(如果它失败了，它会杀死某人)，那么它需要以这样一种方式来编写，它要么是故障安全的，要么是从这种失败中自动恢复。所有其他节目，YMMV。

丰田就是一个很好的例子。说什么你会关于油门电缆，但它是不软件。

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

小开

内存错误是真实存在的，ECC内存确实有帮助。正确实现的ECC内存将纠正单比特错误并检测双比特错误(如果检测到这种错误，则停止系统)。您可以从人们经常抱怨通过运行Memtest86和发现坏内存来解决的软件问题中看到这一点。当然，由宇宙射线引起的短暂故障与内存的持续故障是不同的，但它与更广泛的问题有关，即你应该在多大程度上相信你的内存能够正确运行。

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

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

不幸的是，页面中的海盗链接似乎已经死亡，所以点击这里查看海盗链接。

小开

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

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

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

小开

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

例如，Stratus Technology构建了名为ftServer的Wintel服务器，它有2或3个锁步“主板”，比较计算结果。(有时在太空飞行器中也会这样做)。

Stratus服务器从定制芯片组发展到背板上的同步。

一个非常类似的(但是是软件)系统是基于Hypervisor的VMWare Fault Tolerance lockstep。

小开

注:# EYZ0

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

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

< a href = " http://indico.cern.ch/event/13797/session/0/material/paper/1?contribId=3">大规模CERN 2007研究"数据完整性":供应商声明"比特错误率为10^{-12为他们的内存模块}"， "观察到的错误率比预期低4个数量级"。对于数据密集型任务(8gb /s内存读取)，这意味着单位翻转可能每分钟发生一次(10^-12 vendor BER)或两天发生一次(10^-16 BER)。

2009谷歌的论文"DRAM Errors in the Wild: a Large-Scale Field Study"说每Mbit可以有高达25000-75000个one-bit FIT (failure in time in per billion hours)，经过我的计算，这等于8GB RAM每小时1 - 5位错误。论文同样写道:“平均可纠正错误率为2000-6000 / GB /年”。

2012年Sandia报告“大规模高性能计算静默数据损坏的检测和纠正”:“双位翻转被认为是不可能的”，但在ORNL的密集Cray XT5中，即使有ECC，他们“每天也有75,000多个dimm”。单比特误差应该更高。

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

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

对于更大的机器(10000台服务器)，即使有ECC保护，防止单位错误，正如我们在Sandia 2012年的报告中看到的，每天都可能有双位翻转，所以你将没有机会运行全尺寸并行程序好几天(没有定期的检查点，并从最后一个好的检查点重新启动，以防出现双位错误)。大型机器也会在它们的缓存和cpu寄存器(包括架构和内部芯片的触发器，例如在ALU数据路径中)中进行位翻转，因为不是所有的机器都受到ECC的保护。

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

小开

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

例如，注意用于“嵌入式”应用的英特尔部件倾向于在规格表中添加ECC。平板电脑的Bay Trail没有这个功能，因为它会让内存更贵一些，而且可能速度更慢。而且，如果一台平板电脑千载难逢地崩溃一个程序，用户也不会太在意。无论如何，软件本身远不如硬件可靠。但对于用于工业机械和汽车的sku, ECC是强制性的。从这里开始，我们希望SW更加可靠，而随机打乱的错误将是一个真正的问题。

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

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

小开

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

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

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

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

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

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

小开

宇宙射线事件;在这里的许多答案中被认为是均匀分布的，这可能并不总是正确的(即超新星)。虽然“宇宙射线”;根据定义(至少根据维基百科)来自外空间，我认为将当地的太阳风暴(又名日冕物质抛射)也包括在同一保护伞下是公平的。我相信这可能会导致几个比特在短时间内翻转，可能足以破坏甚至启用ecc的内存。

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

大约10年前，我坐在另一个人旁边，我们各带着笔记本电脑，那是一段相当“风暴”的时期。太阳天气(坐在北极，我们可以间接地观察到这一点——可以看到很多北极光)。突然，在同一时刻，我们的笔记本电脑都死机了。他用的是OS X，而我用的是Linux。我们都不习惯笔记本电脑死机——这在Linux和OS x上是非常罕见的事情，因为我们在不同的操作系统上运行，所以常见的软件故障或多或少可以排除(而且它不是在闰秒内发生的)。我把那件事归结为“宇宙辐射”。

后来，“宇宙辐射”;已经成为我工作场所的一个内部笑话。每当我们的服务器发生了什么事情，我们找不到任何解释，我们开玩笑地把错误归咎于“宇宙辐射”。: -)

小开

作为一个数据点，这发生在我们的构建中:

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

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

我并不是说这是“宇宙射线”，但症状是相符的。