宇宙射线：他们将会影响一个节目的概率是多less？
我又一次在devise审查中，遇到了一个主张，即一个特定情景的概率是“低于宇宙射线的风险”，影响到了这个节目，而且我想到我并没有最清楚的想法是什么概率是。
“由于2 -128是340282366920938463463374607431768211456中的1，所以我认为我们有机会在这里抓住我们的机会，即使这些计算结果是几十亿的因数……我们对于宇宙射线的风险更大把我们搞砸了，我相信。
这个程序员是正确的吗？ 宇宙射线撞击电脑并影响程序执行的可能性是什么？
维基百科 ：
IBM在20世纪90年代进行的研究表明，计算机每月每256 MB RAM通常会遇到一次宇宙射线引起的错误。 [15]
这意味着每个字节每月3.7×10 -9的概率，即1.4×10 -15每字节每秒。 如果你的程序运行1分钟，占用20MB的内存，那么失败的概率是
60 × 20 × 1024² 1 - (1 - 1.4e-15) = 1.8e-6 aka "5 nines"
错误检查可以帮助减less故障后果。 此外，由于Joe所评论的芯片尺寸更小，故障率可能与20年前不同。
显然，不是微不足道的。 从这篇“新科学家”的文章 ，英特尔专利申请引用：
“宇宙射线引起的计算机崩溃已经发生，随着器件（例如晶体pipe）芯片尺寸的减小，预计会随着频率的增加而增加。这个问题预计将成为未来十年计算机可靠性的一个主要限制因素。
你可以在这里阅读完整的专利 。
注意： 这个答案不是关于物理，而是关于非ECC内存模块的无记忆错误。 有些错误可能来自外太空，有些来自桌面的内部空间。
在CERN集群和Google数据中心等大型服务器场中，有几项关于ECC内存故障的研究。 具有ECC的服务器级硬件可以检测和纠正所有单比特错误，并检测许多多比特错误。
我们可以假设有很多非ECC台式机（和非ECC移动智能手机）。 如果我们检查论文的ECC纠错码率（单位翻转），我们可以知道非ECC内存的无记忆损坏率。
-
大规模CERN 2007研究“数据完整性” ：供应商宣称“ 其存储器模块的 误码率为 10 -12 ”，“ 观察到的误码率比预期低4个数量级 ”。 对于数据密集型任务（8 GB / s的存储器读数），这意味着每分钟可以发生一次位翻转（10 -12厂商BER）或两天一次（10 -16 BER）。
-
2009 Google的论文“野外DRAM误差：一项大规模实地研究”指出，每Mbit（ 每十亿小时的失败次数 ）可以达到25000-75000个一位FIT，相当于1 – 5位我的计算后每小时8GB内存的错误。 Paper也这样说：“ 每年每GB 2000-6000的可纠正错误率 ”。
-
2012年桑迪亚报告“大规模高性能计算无声数据损坏的检测和纠正” ：“双位翻转被认为是不太可能的”，但是在ORNL密集的Cray XT5上，他们“以每天75,000个DIMM的速度”与ECC。 单比特错误应该更高。
因此，如果程序有大数据集（几GB），或者具有较高的内存读取或写入速率（GB / s或更高），并且运行了几个小时，那么我们可以期望在桌面硬件上多达几个无声的位翻转。 memtest无法检测到这个速度，而且DRAM模块也不错。
长群集运行在成千上万的非ECC PC上，就像BOINC全网格计算总会有内存位错误以及磁盘和networking无提示错误的错误。
而对于更大的机器（成千上万的服务器），即使ECC保护不受单一位错误的影响，正如我们在Sandia 2012年的报告中所看到的那样，每天可能出现双位翻转，所以您将没有机会运行全尺寸并行程序几天（没有正常的检查点，并在双重错误的情况下从上一个好的检查点重新启动）。 巨大的机器也会在它们的高速caching和CPU寄存器中（比如在ALU数据path中的架构和内部芯片触发器）中获得位翻转，因为它们并不全部都被ECC保护。
PS：如果DRAM模块坏了，情况会更糟糕。 例如，我将新的DRAM安装到笔记本电脑上，几周后死亡。 它开始给大量的内存错误。 我得到：笔记本电脑挂起，Linux重新启动，运行fsck，发现根文件系统上的错误，并表示它想纠正错误后重新启动。 但是在每次下一次重启时（我都是在其中的5-6次左右），在根文件系统上仍然存在错误。
维基百科引用IBM在90年代的一项研究表明，“计算机通常每个月每256MB RAM遇到一个宇宙射线引起的错误”。 不幸的是，引文是“科学美国人”中的一篇文章，没有提供进一步的参考。 就我个人而言，我觉得这个数字非常高，但是也许大多数宇宙射线引起的记忆错误并不会导致任何实际的或者不明显的问题。
另一方面，谈到软件场景的可能性人们通常不知道自己在说什么。
那么，宇宙射线显然是造成了丰田汽车的电子设备发生故障，所以我想说这个概率是非常高的:)
宇宙射线是否真的造成了丰田的灾难？
使用ECC可以纠正宇宙射线的1位错误。 为了避免10％的宇宙射线导致2比特错误的情况，ECC单元通常交错在芯片上，所以没有两个单元彼此相邻。 影响两个单元的宇宙射线事件将导致两个可纠正的1位错误。
Sun指出：（2002年4月816-5053-10）
一般来说，宇宙射线软错误在DRAM存储器中以〜10到100 FIT / MB的速率发生（1 FIT = 1个设备在10亿小时内失效）。 因此，一个具有10 GB内存的系统应该每隔1000到10000小时显示一个ECC事件，而一个100 GB的系统每隔100到1000小时显示一个事件。 但是，这是一个粗略的估计，它将随着上述效应而变化。
内存错误是真实的，ECC内存确实有帮助。 正确实施的ECC内存将纠正单个位错误并检测双位错误（如果检测到这样的错误，则停止系统）。您可以从人们经常抱怨通过运行Memtest86解决的软件问题，发现不好的记忆。 当然，由宇宙射线造成的瞬间失效与一贯失败的记忆是不同的，但它与更广泛的问题有关，即你应该相信你的记忆能够正确地运作。
基于20 MB常驻大小的分析可能适用于微不足道的应用程序，但大型系统通常具有多个主存储器大的服务器。
有趣的链接： http : //cr.yp.to/hardware/ecc.html
不幸的是，页面中的Corsair链接似乎已经死亡。
如果一个程序对生命至关重要（如果某个程序失败了，它将会被杀死），这个程序需要写成可以自动保护的程序，或者自动从这个故障中恢复。 所有其他程序，YMMV。
丰田就是一个例子。 说一下油门电缆，但不是软件。
我曾经编程过要在太空中飞行的设备，然后你（据说从来没有人向我展示任何关于它的文件，但据说这是商业上的常识）可以期待宇宙射线始终引发错误。
这是一个真正的问题，这就是ECC内存用于服务器和embedded式系统的原因。 以及为什么飞行系统与地面系统不同。
例如，请注意，注定要用于“embedded式”应用程序的英特尔部件倾向于将ECC添加到规格表。 一个平板电脑的Bay Trail缺乏它，因为它会使内存有点贵，可能会更慢。 而如果一款平板电脑每一次都在蓝色的月亮中坠毁，那么用户并不在乎。 无论如何，软件本身的可靠性远不如硬件。 但是对于打算用于工业机械和汽车的SKU，ECC是强制性的。 由于这里，我们预计软件可靠性要高得多，而随机翻转造成的错误将是一个真正的问题。
经过IEC 61508和类似标准authentication的系统通常都具有启动testingfunction，可以检查所有的RAM是否正常工作（没有位卡在零位或一位），以及在运行时尝试从ECC检测到的错误中恢复的error handling;通常还有内存擦除任务，不断读写内存，以确保发生的任何错误得到注意。
但是对于主stream的PC软件？ 没什么大不了的。 对于长期服务器？ 使用ECC和故障处理程序。 如果一个无法纠正的错误杀死了内核，那就这样吧。 或者你偏执狂，并使用冗余系统锁步执行，以便如果一个核心被破坏，另一个核心可以接pipe，而第一个核心重新启动。
更多的时候，噪音会破坏数据。 校验和被用来在很多层面上与之对抗。 在数据线中，通常有一个与数据一起传输的奇偶校验位 。 这大大降低了腐败的可能性。 然后在parsing级别上，通常会忽略无意义的数据，所以即使某些损坏已经超过了奇偶校验位或其他校验和，在大多数情况下也会被忽略。
此外，一些组件被电屏蔽，以阻止噪音（可能不是宇宙射线，我猜）。
但最后，正如其他答复者所说的那样，有偶尔的位或字节被扰乱，这是否是一个重要的字节是偶然的。 最好的情况是，宇宙射线扰乱了一个空位，并且完全没有效果，或者使计算机崩溃（这是一件好事，因为计算机不会受到伤害）。 但最坏的情况，好吧，我相信你可以想象。
“宇宙射线事件”在这里的许多答案中被认为具有统一的分布，这可能并非总是如此（即超新星）。 尽pipe根据定义（至less根据维基百科），“宇宙射线”来自外太空 ，但我认为也包括当地的太阳风暴（又名同一伞下的日冕物质抛射）是公平的，我相信它可能会导致一些位时间短，甚至足以破坏ECC启用的存储器。
众所周知，太阳风暴会对电力系统造成一些破坏（如1989年3月的魁北克停电 ）。 计算机系统很可能也会受到影响。
大约10年前，我正坐在另一个人旁边，我们坐在每台笔记本电脑旁边，正处在一个相当“暴风雨”的太阳天气时期（坐在北极地区，我们可以间接地观察到 – 北极光很多可见）。 突然 – 在同一瞬间 – 我们的笔记本电脑都坠毁了。 他正在运行OS X，并且正在运行Linux。 我们都不习惯笔记本电脑的崩溃 – 这在Linux和OS X上是非常罕见的。通常的软件错误可以或多或less的被排除，因为我们运行在不同的操作系统上（并且在飞跃期间没有发生第二）。 我已经把这个事件归因于“宇宙辐射”。
后来，“宇宙辐射”已经成为我工作中的一个内部笑话。 无论什么时候我们的服务器发生什么事情，我们都找不到任何解释，我们开玩笑地将故障归因于“宇宙辐射”。 🙂
我曾经历过这样的事情 – 宇宙射线翻转一点并不罕见，但是一个人不太可能观察到这一点。
我在2004年为一个安装程序开发了一个压缩工具。我的testing数据是一些大约500MB或更多的解压缩的Adobe安装文件。
经过繁琐的压缩运行和解压缩运行来testing完整性，FC / B显示一个字节不同。
在这一个字节里，MSB翻转了。 我也翻了翻，担心我有一个疯狂的bug，只会在非常特殊的情况下出现 – 我甚至不知道从哪里开始寻找。
但有些事情告诉我再次进行testing。 我跑了，它通过了。 我build立了一个脚本，在一夜之间运行testing5次。 早上五点过去了。
所以这绝对是一个宇宙射线翻转。
你也许想看看容错硬件。
例如，Stratus Technology构build了一个名为ftServer的Wintel服务器，该服务器拥有2个或3个“主板”，并将计算结果进行比较。 （有时这也是在太空飞行器中完成的）。
Stratus服务器从定制芯片组发展到背板上的锁步。
一个非常相似的（但是软件）系统是基于Hypervisor的VMWare Fault Tolerance锁步。
作为一个数据点，这只是发生在我们的构build：
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 - ^
这看起来非常强烈，就像编译过程中发生的一些翻转事件，偶然发生在源文件中非常重要的地方。
我不一定说这是一个“宇宙射线”，但症状匹配。
