我又一次在设计评审中遇到了这样的说法,即某个特定场景的概率“小于宇宙射线影响程序的风险”,我突然意识到我根本不知道这个概率是多少。

“既然2-128是340282366920938463463374607431768211456中的1,我认为我们有理由在这里冒险,即使这些计算有几十亿倍的偏差……我相信,宇宙射线把我们搞砸的风险更大。”

这个程序员正确吗? 宇宙射线击中计算机并影响程序执行的概率是多少?


当前回答

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

不幸的是,海盗链接在页面似乎死了,所以查看海盗链接在这里代替。

其他回答

从维基百科:

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年前不同。

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

不幸的是,海盗链接在页面似乎死了,所以查看海盗链接在这里代替。

维基百科引用了IBM在90年代的一项研究,该研究表明“计算机通常每个月每256兆字节的RAM中会出现一次宇宙射线引起的错误。”不幸的是,引用的是《科学美国人》上的一篇文章,该文章没有提供任何进一步的参考文献。就我个人而言,我发现这个数字非常高,但也许大多数由宇宙射线引起的记忆错误不会引起任何实际或明显的问题。

另一方面,当涉及到软件场景时,人们谈论概率通常不知道他们在谈论什么。

使用ECC,您可以纠正宇宙射线的1位错误。为了避免10%的宇宙射线导致2位错误的情况,ECC细胞通常交错在芯片上,因此没有两个细胞彼此相邻。因此,影响两个单元格的宇宙射线事件将导致两个可纠正的1bit误差。

孙声明:(2002年4月第816-5053-10部分)

一般来说,宇宙射线软误差发生在DRAM存储器中 速率~10到100 FIT/MB (1 FIT = 1个设备故障在10亿小时)。 因此,具有10gb内存的系统应该每1000次显示一次ECC事件 到10,000小时,100gb的系统将显示一个事件 100到1000小时。然而,这只是一个粗略的估计 变化是上述效应的函数。

作为一个数据点,这发生在我们的构建中:

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  - ^

这看起来非常像在编译过程中偶然在源文件中非常重要的位置发生的位翻转。

我并不是说这是“宇宙射线”,但症状是相符的。