我再一次进行了设计评审，并且遇到了一个声称，即某个特定场景的概率“低于宇宙射线的风险”影响了该程序，而且我发现我没有最清楚的想法是什么概率是。
“因为2 -128是340282366920938463463374607431768211456中的1个，我认为我们在这里抓住机会是合理的，即使这些计算已经减少了几十亿......我们对宇宙射线的风险更大我相信，把我们搞砸了。“
这个程序员是否正确？ 宇宙射线撞击计算机并影响程序执行的概率是多少？
#1楼
您可能还想查看Fault Tolerant硬件。
例如，Stratus Technology构建名为ftServer的Wintel服务器，它具有锁定步骤的2或3个“主板”，比较计算结果。 （这也有时在太空飞行器上完成）。
Stratus服务器从定制芯片组演变为背板上的锁步。
一个非常相似（但软件）的系统是基于Hypervisor的VMWare Fault Tolerance锁步。
#2楼
注意： 这个答案不是关于物理，而是关于非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错误：一场大规模的现场研究”表示每Mbit可以有高达25000-75000的一位FIT（ 每十亿小时的失败时间 ），相当于1到5位计算后，每小时8GB内存的错误。 Paper说同样的话：“ 每年每GB标准的可纠正错误率为2000-6000 ”。
2012 Sandia报告“检测和纠正大规模高性能计算的无声数据损坏” ：“双位翻转被认为不太可能”但是在ORNL的密集Cray XT5中，它们“以每天75,000+ DIMM的速率”，甚至与ECC。 并且单比特错误应该更高。
因此，如果程序具有大型数据集（几GB），或者具有高内存读取或写入速率（GB / s或更高），并且运行了几个小时，那么我们可以预期桌面硬件上会有多个静默位翻转。 memtest无法检测到这个速率，DRAM模块也很好。
长集群在数千台非ECC PC上运行，如BOINC互联网范围的网格计算将始终存在来自内存位翻转以及磁盘和网络静默错误的错误。
对于更大的机器（10万台服务器），即使是针对单比特错误的ECC保护，正如我们在Sandia 2012年报告中看到的那样，每天都会有双位翻转，因此您将无法运行全尺寸并行程序连续几天（如果出现双重错误，无需定期检查点并从最后一个好的检查点重新启动）。 巨大的机器也将在其缓存和cpu寄存器中获得位翻转（架构和内部芯片的触发器，例如在ALU数据路径中），因为并非所有这些都受ECC保护。
PS：如果DRAM模块坏了，情况会更糟。 例如，我在笔记本电脑上安装了新的DRAM，几周后就死了。 它开始产生很多内存错误。 我得到的：笔记本电脑挂起，Linux重新启动，运行fsck，发现根文件系统上的错误，并表示它想在纠正错误后重新启动。 但是在每次下次重启时（我做了大约5-6次），根文件系统上仍然存在错误。
#3楼
来自维基百科 ：
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年前不同。
#4楼
维基百科援引IBM在90年代进行的一项研究表明，“计算机通常每月每256兆字节RAM会出现一次宇宙射线引起的错误。” 不幸的是，引用的是科学美国人的一篇文章，该文章没有给出任何进一步的参考。 就个人而言，我发现这个数字非常高，但也许宇宙射线引起的大多数记忆错误都不会引起任何实际或明显的问题。
另一方面，当谈到软件场景时，人们谈论概率通常不知道他们在谈论什么。
#5楼
显然，并非无足轻重。 来自这篇新科学家的文章 ，来自英特尔专利申请的引用：
“由于设备（例如，晶体管）的芯片尺寸减小，宇宙射线诱发的计算机崩溃已经发生并且预计随着频率的增加而增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”
#6楼
更常见的是，噪音可能会破坏数据。 校验和用于在许多层面上对抗这种情况; 在数据电缆中，通常存在与数据一起行进的奇偶校验位 。 这大大降低了腐败的可能性。 然后在解析级别时，通常忽略无意义数据，因此即使某些损坏确实超过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。
此外，一些组件是电屏蔽的，以阻挡噪音（我猜可能不是宇宙射线）。
但最后，正如其他回答者所说的那样，偶尔会有一些比特或字节被扰乱，并且无论这是否是一个重要的字节都是偶然的。 最好的情况是，一个宇宙射线扰乱其中一个空位并且完全没有效果，或者使计算机崩溃（这是一件好事，因为计算机不会受到伤害）; 但最坏的情况是，我相信你可以想象。
#7楼
好吧，宇宙射线显然导致丰田汽车中的电子设备发生故障，所以我想说概率非常高:)
#8楼
我曾经编写了在太空中飞行的设备，然后你（据说，没有人向我展示任何关于它的论文，但据说这是业务中的常识）可能期望宇宙射线一直引发错误。
#9楼
如果某个程序对生命至关重要（如果某个程序失败就会杀死它），它需要以一种故障安全方式编写，或者从这种故障中自动恢复。 所有其他程序，YMMV。
丰田汽车就是一个很好的例子。 说出你对油门电缆的看法，但它不是软件。
另见http://en.wikipedia.org/wiki/Therac-25
#10楼
内存错误是真实的，ECC内存确实有帮助。 正确实现的ECC内存将纠正单个位错误并检测双位错误（如果检测到这样的错误，则停止系统。）您可以通过运行Memtest86来解决通常情况下人们抱怨通常是什么样的软件问题。发现不好的记忆。 当然，由宇宙射线引起的瞬态故障与始终存在故障的记忆不同，但它与更广泛的问题相关，即你应该相信你的记忆能够正常运行多少。
基于20 MB常驻大小的分析可能适用于普通应用程序，但是大型系统通常具有多个具有大主存储器的服务器。
有趣的链接： http ： //cr.yp.to/hardware/ecc.html
不幸的是，页面中的Corsair链接似乎已经死了。
#11楼
这是一个真正的问题，这就是ECC内存用于服务器和嵌入式系统的原因。 为什么飞行系统不同于地面飞行系统。
例如，请注意，用于“嵌入式”应用程序的英特尔部件往往会在规格表中添加ECC。 平板电脑的Bay Trail缺乏它，因为它会使内存更昂贵并且可能更慢。 如果平板电脑每次在蓝色月亮中崩溃一个程序，用户就不会太在意了。 无论如何，软件本身远不如硬件可靠。 但对于打算用于工业机械和汽车的SKU，ECC是强制性的。 从这里开始，我们期望SW更可靠，随机扰动的错误将是一个真正的问题。
经过IEC 61508和类似标准认证的系统通常都有启动测试，可以检查所有RAM是否正常工作（没有位卡在零或一个位置），以及运行时尝试从ECC检测到的错误中恢复的错误处理，以及通常还会执行内存清理程序任务，并持续读取和写入内存，以确保发生的任何错误都会被注意到。
但对于主流PC软件？ 没有大碍。 对于长寿命的服务器？ 使用ECC和错误处理程序。 如果无法纠正的错误导致内核崩溃，那就这样吧。 或者你变得偏执并使用具有锁定步骤执行的冗余系统，这样如果一个核心被破坏，另一个核心可以在第一个核心重新启动时接管。
#12楼
我已经经历过这一点 - 宇宙射线翻转一点并不罕见，但一个人观察它的可能性很小。
我在2004年为安装程序开发了一个压缩工具。我的测试数据是一些大约500 MB或更多解压缩的Adobe安装文件。
经过繁琐的压缩运行和解压缩运行以测试完整性后，FC / B显示一个字节不同。
在那一个字节内，MSB翻转了。 我也转过身来，担心我有一个只会在非常特殊的情况下出现的疯狂的错误 - 我甚至不知道从哪里开始寻找。
但有些事告诉我再次进行测试。 我跑了它，它通过了。 我设置了一个脚本，在一夜之间运行测试5次。 所有5人早上都过去了。
所以这绝对是一个宇宙射线位翻转。
#13楼
在这里的许多答案中，“宇宙射线事件”被认为具有均匀分布，这可能并非总是如此（即超新星）。 虽然根据定义（至少根据维基百科）的“宇宙射线”来自外太空 ，但我认为同样包括当地的太阳风暴（也就是在同一把伞下的日冕物质抛射）是公平的。我相信它可能导致几个位在短时间跨度，甚至可能破坏启用ECC的内存。
众所周知，太阳风暴会对电力系统造成相当大的破坏（如1989年3月的魁北克停电 ）。 计算机系统很可能也会受到影响。
大约10年前，我坐在另一个人的旁边，我们坐在我们的每台笔记本电脑上，这是一个充满“暴风雨”太阳天气的时期（坐在北极，我们可以间接地观察到这一点 - 很多北极光到可见）。 突然 - 在同一时刻 - 我们的笔记本电脑都崩溃了。 他正在运行OS X，我正在运行Linux。 我们都不习惯笔记本电脑崩溃 - 这在Linux和OS X上是一件非常罕见的事情。由于我们在不同的操作系统上运行，所以可以或多或少地排除常见的软件错误（并且它在飞跃过程中没有发生过第二）。 我把这个事件归结为“宇宙辐射”。
后来，“宇宙辐射”已成为我职场的一个内部笑话。 每当我们的服务器出现问题而我们找不到任何解释时，我们开玩笑地将故障归结为“宇宙辐射”。 :-)
#14楼
作为一个数据点，这恰好发生在我们的构建上：
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 - ^
这看起来非常像在编译期间发生翻转，在源文件中非常重要的地方偶然发生。
我不一定说这是“宇宙射线”，但症状是匹配的。
#15楼
使用ECC，您可以纠正宇宙射线的1位错误。 为了避免宇宙射线导致2位错误的10％的情况，ECC单元通常在芯片上交错，因此没有两个单元彼此相邻。 因此，影响两个单元的宇宙射线事件将导致两个可校正的1位误差。
太阳州:( 2002年4月第816-5053-10号）
一般而言，宇宙射线软错误在DRAM存储器中以~10到100 FIT / MB的速率发生（1 FIT = 1个设备在10亿小时内失效）。 因此，具有10 GB内存的系统应每1,000至10,000小时显示一次ECC事件，而100 GB的系统每100至1,000小时显示一次事件。 然而，这是一个粗略的估计，将随着上述效果的变化而变化。
