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