我又一次在进行设计审查时，遇到了这样一种说法，即特定场景的概率“小于宇宙射线的风险”影响程序，我突然想到我根本不知道那是什么概率是。
“由于 2 -128是 340282366920938463463374607431768211456 中的 1 个，我认为我们有理由在这里冒险，即使这些计算偏离了几十亿倍......我们面临的宇宙射线风险更大把我们搞砸了，我相信。”
这个程序员是对的吗？宇宙射线撞击计算机并影响程序执行的概率是多少？
问问题
66569 次
15 回答
69
注意：这个答案不是关于物理的，而是关于非 ECC 内存模块的静默内存错误。有些错误可能来自外太空，有些则来自桌面的内部空间。
在 CERN 集群和 Google 数据中心等大型服务器场上，有几项 ECC 内存故障研究。具有 ECC 的服务器级硬件可以检测和纠正所有单比特错误，并检测许多多比特错误。
我们可以假设有很多非 ECC 桌面（和非 ECC 移动智能手机）。如果我们检查 ECC 可纠正错误率（单比特翻转）的论文，我们可以知道非 ECC 内存上的静默内存损坏率。
大规模 CERN 2007 研究“数据完整性”：供应商宣称“ 其内存模块的误码率为10 -12 ”，“观察到的误码率比预期低 4 个数量级”。对于数据密集型任务（8 GB/s 的内存读取），这意味着可能每分钟发生一次位翻转（10 -12供应商 BER）或两天一次（10 -16 BER）。
2009 年谷歌的论文“DRAM Errors in the Wild: A Large-Scale Field Study”说，每 Mbit 可以有高达 25000-75000 位 FIT（每十亿小时的故障时间），等于 1-5 位经过我的计算，每小时 8GB RAM 的错误。论文也这么说：“平均每年每 GB 2000–6000 的可纠正错误率”。
2012 年桑迪亚报告“大规模高性能计算的静默数据损坏的检测和纠正”：“双位翻转被认为不太可能”，但在 ORNL 的密集 Cray XT5 中，它们“以每天 1 次的速度处理 75,000 多个 DIMM”甚至与 ECC。并且单位错误应该更高。
因此，如果程序有很大的数据集（几 GB），或者有很高的内存读取或写入速率（GB/s 或更多），并且运行了几个小时，那么我们可以预期桌面硬件上最多有几个静默位翻转。memtest检测不到这个速率，DRAM模块很好。
长集群在数以千计的非 ECC PC 上运行，例如 BOINC 互联网范围的网格计算总是会出现来自内存位翻转以及磁盘和网络静默错误的错误。
对于更大的机器（10,000 台服务器），即使有 ECC 保护以防止单位错误，正如我们在 Sandia 的 2012 年报告中看到的那样，每天都可能发生双位翻转，因此您将没有机会运行全尺寸并行程序几天（没有定期检查点并从最后一个好的检查点重新启动，以防出现双重错误）。大型机器的缓存和 cpu 寄存器也会发生位翻转（架构和内部芯片的触发器，例如 ALU 数据路径中的触发器），因为并非所有机器都受 ECC 保护。
PS：如果 DRAM 模块坏了，情况会更糟。例如，我在笔记本电脑中安装了新的 DRAM，几周后它就死了。它开始出现很多内存错误。我得到的是：笔记本电脑挂起，Linux 重新启动，运行 fsck，在根文件系统上发现错误，并说它想在纠正错误后重新启动。但是在每次下一次重新启动时（我做了大约 5-6 次），在根文件系统上仍然会发现错误。
于 2014-05-11T00:14:57.810 回答
31
好吧，宇宙射线显然导致丰田汽车中的电子设备发生故障，所以我会说概率非常高:)
于 2010-04-05T20:28:21.590 回答
27
使用 ECC，您可以纠正宇宙射线的 1 位错误。为了避免宇宙射线导致 2 位错误的 10% 情况，ECC 单元通常在芯片上交错，因此没有两个单元彼此相邻。因此，影响两个细胞的宇宙射线事件将导致两个可纠正的 1 位错误。
Sun 指出：（部件号 816-5053-10 April 2002）
一般来说，在 DRAM 内存中，宇宙射线软错误的发生率约为 10 到 100 FIT/MB（1 FIT = 1 个设备在 10 亿小时内发生故障）。因此，具有 10 GB 内存的系统应每 1,000 到 10,000 小时显示一次 ECC 事件，而具有 100 GB 内存的系统将每 100 到 1,000 小时显示一次事件。然而，这是一个粗略的估计，会随着上述效应的变化而变化。
于 2011-04-10T05:41:46.820 回答
17
内存错误是真实存在的，ECC 内存确实有帮助。正确实现的 ECC 内存将更正单比特错误并检测双比特错误（如果检测到此类错误，系统将停止。）您可以从人们经常抱怨似乎是通过运行Memtest86解决的软件问题和发现不好的记忆。当然，由宇宙射线引起的短暂故障与持续故障的记忆片段不同，但它与更广泛的问题有关，即您应该在多大程度上相信自己的记忆能够正确运行。
基于 20 MB 常驻大小的分析可能适用于微不足道的应用程序，但大型系统通常具有多个具有大型主存储器的服务器。
有趣的链接：http ://cr.yp.to/hardware/ecc.html
不幸的是，页面中的 Corsair 链接似乎已失效，因此请在此处查看 Corsair 链接。
于 2010-04-06T05:27:23.740 回答
16
这是一个真正的问题，这就是为什么在服务器和嵌入式系统中使用 ECC 内存的原因。以及为什么飞行系统与地面系统不同。
例如，请注意，用于“嵌入式”应用程序的英特尔部件往往会将 ECC 添加到规格表中。平板电脑的 Bay Trail 缺少它，因为它会使内存更贵，而且可能更慢。而且，如果平板电脑每隔一段时间就会崩溃一次程序，那么用户也不会太在意。无论如何，软件本身远不如硬件可靠。但对于旨在用于工业机械和汽车的 SKU，ECC 是强制性的。从这里开始，我们希望 SW 更加可靠，并且随机扰动的错误将是一个真正的问题。
通过 IEC 61508 和类似标准认证的系统通常具有启动测试以检查所有 RAM 是否正常工作（没有位卡在零或一），以及在运行时尝试从 ECC 检测到的错误中恢复的错误处理，以及通常还有内存清理任务，这些任务会不断地读取和写入内存，以确保发现发生的任何错误。
但是对于主流PC软件呢？没有大碍。对于一个长寿命的服务器？使用 ECC 和故障处理程序。如果一个不可纠正的错误杀死了内核，那就这样吧。或者你偏执并使用具有锁步执行的冗余系统，这样如果一个核心损坏，另一个核心可以在第一个核心重新启动时接管。
于 2014-11-06T11:10:41.213 回答
12
如果一个程序对生命至关重要（如果它失败，它会杀死某人），它需要以这样的方式编写，它要么是故障安全的，要么是从这种故障中自动恢复的。所有其他程序，YMMV。
丰田汽车就是一个例子。说出您对油门电缆的看法，但它不是软件。
于 2010-04-06T03:02:33.373 回答
11
我曾经编写过要在太空中飞行的设备，然后你（据说从来没有人给我看过任何关于它的论文，但据说这是业内的常识）可以预期宇宙射线会一直引发错误。
于 2010-04-05T21:16:44.087 回答
11
“宇宙射线事件”在这里的许多答案中被认为具有均匀分布，这可能并不总是正确的（即超新星）。尽管根据定义（至少根据维基百科），“宇宙射线”来自外太空，但我认为将局部太阳风暴（又称日冕物质抛射）也包括在同一保护伞下是公平的。我相信它可能会导致几个位在短时间内翻转，甚至可能足以破坏启用 ECC 的内存。
众所周知，太阳风暴会对电力系统造成相当大的破坏（例如1989 年 3 月的魁北克停电）。计算机系统很可能也会受到影响。
大约 10 年前，我坐在另一个人旁边，我们每个人都坐在笔记本电脑旁，那是一个相当“暴风雨”的太阳天气时期（坐在北极，我们可以间接观察到这一点 - 很多北极光可见）。突然——在同一瞬间——我们的两台笔记本电脑都崩溃了。他运行的是 OS X，而我运行的是 Linux。我们俩都不习惯笔记本电脑崩溃——这在 Linux 和 OS X 上是非常罕见的事情。常见的软件错误可以或多或少地被排除，因为我们在不同的操作系统上运行（而且它并没有在飞跃期间发生）第二）。我已经把那个事件归因于“宇宙辐射”。
后来，“宇宙辐射”成了我公司内部的笑话。每当我们的服务器出现问题而我们找不到任何解释时，我们开玩笑地将故障归咎于“宇宙辐射”。:-)
于 2015-05-21T10:16:22.033 回答
7
更常见的是，噪声会破坏数据。校验和用于在许多层面上解决这个问题；在数据电缆中，通常有一个奇偶校验位与数据一起传输。这大大降低了腐败的可能性。然后在解析级别，通常会忽略无意义的数据，因此即使某些损坏确实通过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。
此外，一些组件被电屏蔽以阻挡噪音（我猜可能不是宇宙射线）。
但最后，正如其他回答者所说，偶尔会有比特或字节被打乱，这是否是一个重要字节取决于机会。最好的情况是，宇宙射线扰乱了一个空位并且完全没有影响，或者使计算机崩溃（这是一件好事，因为计算机不会受到伤害）；但最坏的情况，好吧，我相信你可以想象。
于 2010-04-05T20:27:45.523 回答
6
我经历过——宇宙射线翻转一点并不罕见，但一个人观察到这一点的可能性很小。
我在 2004 年为安装程序开发压缩工具。我的测试数据是一些大约 500 MB 或更多解压缩的 Adobe 安装文件。
经过乏味的压缩运行和测试完整性的解压缩运行，FC /B 显示一个字节不同。
在那一个字节内，MSB 翻转了。我也翻转了，担心我有一个疯狂的错误，只会在非常特定的条件下浮出水面——我什至不知道从哪里开始寻找。
但是有些东西告诉我再次运行测试。我跑了它，它通过了。我设置了一个脚本在一夜之间运行测试 5 次。早上5个都过去了。
所以那绝对是宇宙射线位翻转。
于 2015-05-13T16:04:35.377 回答
4
您可能还想看看容错硬件。
例如，Stratus Technology 构建了名为 ftServer 的 Wintel 服务器，该服务器有 2 或 3 个“主板”以同步方式比较计算结果。（这有时也在太空飞行器中完成）。
Stratus 服务器从定制芯片组演变为背板上的锁步。
一个非常相似（但软件）的系统是基于 Hypervisor 的 VMWare 容错锁步。
于 2013-09-26T02:33:30.863 回答
4
作为一个数据点，这只是发生在我们的构建中：
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 - ^
这看起来非常像在编译期间发生的一点翻转，偶然在源文件中的一个非常重要的位置。
我不一定说这是“宇宙射线”，但症状匹配。
于 2016-05-23T11:10:56.893 回答