我又一次在设计评审中遇到了这样的说法,即某个特定场景的概率“小于宇宙射线影响程序的风险”,我突然意识到我根本不知道这个概率是多少。
“既然2-128是340282366920938463463374607431768211456中的1,我认为我们有理由在这里冒险,即使这些计算有几十亿倍的偏差……我相信,宇宙射线把我们搞砸的风险更大。”
这个程序员正确吗? 宇宙射线击中计算机并影响程序执行的概率是多少?
我又一次在设计评审中遇到了这样的说法,即某个特定场景的概率“小于宇宙射线影响程序的风险”,我突然意识到我根本不知道这个概率是多少。
“既然2-128是340282366920938463463374607431768211456中的1,我认为我们有理由在这里冒险,即使这些计算有几十亿倍的偏差……我相信,宇宙射线把我们搞砸的风险更大。”
这个程序员正确吗? 宇宙射线击中计算机并影响程序执行的概率是多少?
当前回答
如果一个程序是生命攸关的(如果它失败了,它会杀死某人),那么它需要以这样一种方式来编写,它要么是故障安全的,要么是从这种失败中自动恢复。所有其他节目,YMMV。
丰田就是一个很好的例子。说什么你会油门电缆,但它不是软件。
参见http://en.wikipedia.org/wiki/Therac-25
其他回答
从维基百科:
IBM在20世纪90年代的研究表明,计算机通常每个月每256兆字节的RAM会经历一次宇宙射线引起的错误
这意味着每月每个字节的概率为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年前不同。
作为一个数据点,这发生在我们的构建中:
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 - ^
这看起来非常像在编译过程中偶然在源文件中非常重要的位置发生的位翻转。
我并不是说这是“宇宙射线”,但症状是相符的。
显然,这并非微不足道。这篇《新科学家》的文章引用了一份英特尔专利申请:
“宇宙射线引发的电脑死机已经发生过,而且随着芯片中器件(例如晶体管)尺寸的减小,预计死机的频率将会增加。这个问题预计将成为未来十年计算机可靠性的主要限制因素。”
你可以在这里阅读完整的专利。
我曾经为在太空中飞行的设备编程,然后你(据说,没有人给我看过任何关于这方面的论文,但据说这是业内的常识)可以预期宇宙射线总是会导致错误。
Memory errors are real, and ECC memory does help. Correctly implemented ECC memory will correct single bit errors and detect double bit errors (halting the system if such an error is detected.) You can see this from how regularly people complain about what seems to be a software problem that is resolved by running Memtest86 and discovering bad memory. Of course a transient failure caused by a cosmic ray is different to a consistently failing piece of memory, but it is relevant to the broader question of how much you should trust your memory to operate correctly.
基于20 MB常驻大小的分析可能适用于普通应用程序,但大型系统通常有多个具有较大主存的服务器。
有趣的链接:http://cr.yp.to/hardware/ecc.html
不幸的是,海盗链接在页面似乎死了,所以查看海盗链接在这里代替。