我又一次在设计评审中遇到了这样的说法，即某个特定场景的概率“小于宇宙射线影响程序的风险”，我突然意识到我根本不知道这个概率是多少。
“既然2-128是340282366920938463463374607431768211456中的1，我认为我们有理由在这里冒险，即使这些计算有几十亿倍的偏差……我相信，宇宙射线把我们搞砸的风险更大。”
这个程序员正确吗? 宇宙射线击中计算机并影响程序执行的概率是多少?
当前回答
显然，这并非微不足道。这篇《新科学家》的文章引用了一份英特尔专利申请:
“宇宙射线引发的电脑死机已经发生过，而且随着芯片中器件(例如晶体管)尺寸的减小，预计死机的频率将会增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”
你可以在这里阅读完整的专利。
其他回答
我曾经为在太空中飞行的设备编程，然后你(据说，没有人给我看过任何关于这方面的论文，但据说这是业内的常识)可以预期宇宙射线总是会导致错误。
您可能还想看看容错硬件。
例如，Stratus Technology构建了名为ftServer的Wintel服务器，它有2或3个锁步“主板”，比较计算结果。(有时在太空飞行器中也会这样做)。
Stratus服务器从定制芯片组发展到背板上的同步。
一个非常类似的(但是是软件)系统是基于Hypervisor的VMWare Fault Tolerance lockstep。
显然，这并非微不足道。这篇《新科学家》的文章引用了一份英特尔专利申请:
“宇宙射线引发的电脑死机已经发生过，而且随着芯片中器件(例如晶体管)尺寸的减小，预计死机的频率将会增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”
你可以在这里阅读完整的专利。
作为一个数据点，这发生在我们的构建中:
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内存。以及为什么飞行系统与地面系统不同。
For example, note that Intel parts destined for "embedded" applications tend to add ECC to the spec sheet. A Bay Trail for a tablet lacks it, since it would make the memory a bit more expensive and possibly slower. And if a tablet crashes a program every once in a blue moon, the user does not care much. The software itself is far less reliable than the HW anyway. But for SKUs intended for use in industrial machinery and automotive, ECC is mandatory. Since here, we expect the SW to be far more reliable, and errors from random upsets would be a real issue.
通过IEC 61508和类似标准认证的系统通常都有启动测试，检查所有RAM是否正常(没有位卡在0或1)，以及运行时的错误处理，试图从ECC检测到的错误中恢复，通常还有内存清除任务，不断地遍历和读写内存，以确保发生的任何错误都能被注意到。
但是对于主流PC软件来说呢?没什么大不了的。对于长期存在的服务器?使用ECC和故障处理程序。如果一个不可纠正的错误杀死了内核，那就这样吧。或者你偏执地使用带有锁步执行的冗余系统，这样如果一个核心损坏，另一个核心可以在第一个核心重新启动时接管。
