宇宙射线:它们对程序产生影响的概率是多少？

Question

宇宙射线:它们对程序产生影响的概率是多少？

Mar*_*son 529 statistics physics probability error-detection risk-analysis

我再一次进行了设计评审,并且遇到了一个声称特定情景的概率"低于宇宙射线的风险"影响该程序的说法,并且我发现我没有最微弱的想法是什么概率是.

"因为2 ^-128是340282366920938463463374607431768211456中的1个,我认为我们在这里抓住机会是合理的,即使这些计算已经减少了几十亿......我们对宇宙射线的风险更大我相信,把我们搞砸了."

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

Answer 1

ken*_*ytm 301

来自维基百科:

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"

Run Code Online (Sandbox Code Playgroud)

错误检查有助于减少故障的后果.此外,由于Joe评论的芯片尺寸更紧凑,故障率可能与20年前不同.

缩小尺寸肯定会增加风险.用于航天器的硬化处理器使用非常大的特征尺寸来避免宇宙射线效应. (60认同)
不仅是宇宙射线,芯片中使用的材料中的放射性同位素是一个更大的问题.制造商竭尽全力确保硅,焊料,封装等不含任何α或β发射体. (21认同)
是否有可能不是降低风险,减小规模会增加风险,因为改变每个钻头的状态需要更少的能量？ (16认同)
哇!这意味着我的电脑中大约1个字节每两天就会损坏一次. (12认同)
更重要的是,1995年CPU的芯片特征尺寸约为0.35μm或350nm.它现在是35纳米尺寸的1/10. (10认同)
有人认为我对用户机器的风险是,在典型的用户机器上,占用最多RAM的对象,因此最容易被宇宙射线损坏的对象是大型媒体实体,如声音,视频和图片.对于这些对象,s翻转位对计算机的性能或用户看到的内容没有明显的影响.因此,翻转位的概率远大于宇宙射线导致危险行为的概率. (6认同)
改进了错误检查？当该研究发表时,大多数个人计算机在每个内存字节上都有一个奇偶校验位.现在,内存系统上的错误控制电路通常只能在服务器级机器上找到(据我所知),甚至在所有服务器机器上都没有.然而,当今天存储系统上存在错误电路时,它通常是ECC而不仅仅是奇偶校验. (4认同)
“ 5个9”通常表示0.99999而不是0.00001 (4认同)
然后事实上,尽管特征尺寸缩小,但芯片尺寸实际上是_grow_.我想,对于更大的芯片和宇宙射线,它与更大的风帆和风一样吗？ (2认同)
令人遗憾的是看到更多容错处理器（例如 SPARC 等）被半途而废。他们为此类事情内置了各种巧妙的自我纠正机制。哦，看来 x86 架构终于注意到了这个问题，并且也开始针对它进行设计。 (2认同)
@Kevin，单个翻转位实际上可以将 JPG 图像渲染为部分损坏。https://en.wikipedia.org/wiki/Data_degradation#Visual_example (2认同)

Answer 2

ire*_*ses 87

显然,并非无足轻重.来自这篇新科学家的文章,来自英特尔专利申请的引用:

"由于设备(例如,晶体管)的芯片尺寸减小,宇宙射线诱发的计算机崩溃已经发生并且预计随着频率的增加而增加.这个问题预计将成为未来十年计算机可靠性的主要限制因素."

你可以在这里阅读完整的专利.

为什么它们随着芯片尺寸的减小而增加？当然,较小的物体不太可能被射线击中(即比较在墙上投掷网球,将其扔在邮票上) (7认同)
因为随着组件尺寸的缩小,它们对宇宙射线撞击变得更加敏感. (6认同)
@Anko - 这很明显.随着给定元件变小,它需要更少的电压和更少的电荷来设置一点.这使得被外太空能量轰击更加敏感.但是,这里有一个引用:[*随着LSI存储设备变小,它们对核辐射引起的软故障变得更加敏感.*](http://www.pld.ttu.ee/IAF0030/curtis.pdf ) (6认同)
是的,较小的等于被击中的可能性较小,但更有可能是击中将影响该州. (4认同)
@ire_and_curses [需要引证] (2认同)

Answer 3

osg*_*sgx 51

注意:这个答案不是关于物理,而是关于非ECC内存模块的静默内存错误.一些错误可能来自外太空,一些错误来自桌面的内部空间.

在CERN集群和Google数据中心等大型服务器场上,有几项关于ECC内存故障的研究.具有ECC的服务器级硬件可以检测并纠正所有单个位错误,并检测许多多位错误.

我们可以假设有很多非ECC桌面(和非ECC移动智能手机).如果我们检查文件的ECC纠正错误率(单位翻转),我们就可以知道非ECC内存上的静默内存损坏率.

大规模CERN 2007研究"数据完整性":供应商宣称" 其内存模块的误码率为10 ^-12 "," 观察到的错误率比预期低4个数量级 ".对于数据密集型任务(8 GB/s的内存读取),这意味着可以每分钟(10 ^-12供应商BER)或两天一次(10 ^-16 BER)发生单比特翻转.
2009谷歌的论文"疯狂的DRAM错误:一场大规模的现场研究"表示每Mbit可以有高达25000-75000的一位FIT(每十亿小时的失败时间),相当于1到5位计算后,每小时8GB内存的错误.Paper说同样的话:" 每年每GB标准的可纠正错误率为2000-6000 ".
2012 Sandia报告"检测和纠正大规模高性能计算的无声数据损坏":"双位翻转被认为不太可能",但在ORNL的密集Cray XT5中,它们"以每天75,000+ DIMM的速率",甚至与ECC.并且单比特错误应该更高.

因此,如果程序有大量的数据集(几个GB),或拥有高记忆读取或写入速率(GB/s以上),并且它运行了几个小时,那么我们可以预计高达数无声位翻转的桌面硬件.memtest无法检测到这个速率,DRAM模块也很好.

长集群在数千台非ECC PC上运行,如BOINC互联网范围的网格计算将始终存在来自内存位翻转以及磁盘和网络静默错误的错误.

而对于更大的机器(10和数千台服务器),甚至从单比特错误ECC保护,如我们在桑迪亚国家实验室的2012报告中可以看到,可以有双位翻转每一天,这样你就没有机会跑并行全尺寸程序连续几天(如果出现双重错误,无需定期检查点并从最后一个好的检查点重新启动).巨大的机器也将在其缓存和cpu寄存器中获得位翻转(架构和内部芯片的触发器,例如在ALU数据路径中),因为并非所有这些都受ECC保护.

PS:如果DRAM模块坏了,情况会更糟.例如,我在笔记本电脑上安装了新的DRAM,几周后就死了.它开始产生很多内存错误.我得到的:笔记本电脑挂起,Linux重新启动,运行fsck,发现根文件系统上的错误,并表示它想在纠正错误后重新启动.但是在每次下次重启时(我做了大约5-6次),根文件系统上仍然存在错误.

来自BH 2011的其他材料:"Bitsquatting.没有利用的DNS劫持"https://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinaburg_Bitsquatting_WP.pdf列出现代多GB DRAM有大约10000-30000 FIT/Mbit (每128MB的错误之间不到100小时).本文还列出了一些文章,其中得出的结论是[大多数软错误](http://en.wikipedia.org/wiki/Soft_error)来自辐射,几乎所有情况都来自宇宙射线,而某些情况则来自PC内部的α发射器.BH作者做了实验并获得了50000次访问域名,从热门网站改变了1位 (7认同)
在 Google 的论文中，它看起来更像是某些 RAM 损坏的情况_我们机群中大约三分之一的机器和超过 8% 的 DIMM 每年至少出现一个可纠正的错误。我们每个 DIMM 的可纠正错误率转化为每 Mbit 平均 25,000–75,000 FIT（每十亿小时运行中的故障次数）和每 Mbit 778–25,000 的中值 FIT 范围（有错误的 DIMM 的中值），而先前的研究报告每 Mbit 为 200-5,000 FIT。每个 DIMM 的可纠正错误数量变化很大，与其他 DIMM 相比，某些 DIMM 遇到大量错误。_ (2认同)

Answer 4

Jes*_*erE 30

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

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

是的,但是大多数内存都包含数据,其中翻转不是那个visiblp. (74认同)
@zoul.哈哈在'visiblp',但如果e = 1100101和p = 1110000那么你就是*3*位翻转的不幸受害者! (32认同)
@Paul:或**one*finger blip. (9认同)
一位被翻转的概率必须乘以该位对程序有明显影响的概率.我猜第二个概率比你想象的要低很多. (7认同)
@Mark:典型的计算机程序没有内置的那种容错功能.如果执行损坏的代码,程序代码中的单比特错误将更有可能使程序崩溃. (2认同)
@Robert Harvey,不仅大部分程序都是数据,而且很多实际程序都会很少执行.想想为测试获得100%的代码覆盖率是多么艰难.一些指令的变化可能非常微妙.结合所有这些,概率开始变得非常低. (2认同)

Answer 5

Kev*_*ell 29

好吧,宇宙射线显然导致丰田汽车中的电子设备发生故障,所以我想说概率非常高:)

宇宙射线真的会引起丰田的困境吗？

"联邦监管机构正在研究丰田汽车的突然加速是否与宇宙射线有关." 这就是为什么你永远不应该让联邦监管机构掌控你的生活. (23认同)
"显然"？我会说这是一个疯狂的猜测.我自己的猜测是,这种现象是嵌入式系统(实际上是最复杂的计算机系统)的噩梦 - 竞争条件的结果. (16认同)
我猜这里的理论是宇宙射线在老脑中翻转,导致它们发生故障并按下错误的踏板. (13认同)
@Knox:拿出你的旧锡箔帽,它*很有用! (6认同)
这可能不是一个玩笑.我见过一些像以前那样发生的非常奇怪的事情.并不像大多数人想象的那么罕见. (3认同)

Answer 6

eck*_*kes 23

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

太阳州:( 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小时显示一次事件.然而,这是一个粗略的估计,将随着上述效果的变化而变化.

Answer 7

jan*_*anm 17

内存错误是真实的,ECC内存确实有帮助.正确实现ECC内存将纠正单比特错误和检测双位错误(如果检测到这样的错误停止系统.)您可以从人们经常抱怨似乎是通过运行解决的软件问题,看到这个Memtest86是和发现不好的记忆.当然,由宇宙射线引起的瞬态故障与始终存在故障的记忆不同,但它与更广泛的问题相关,即您应该相信您的记忆能够正常运行多少.

基于20 MB常驻大小的分析可能适用于普通应用程序,但大型系统通常具有多个具有大主存储器的服务器.

有趣的链接:http: //cr.yp.to/hardware/ecc.html

不幸的是,页面中的Corsair链接似乎已经死了.

Answer 8

Rob*_*vey 13

如果某个程序对生命至关重要(如果某个程序失败就会杀死它),它需要以一种故障安全方式编写,或者从这种故障中自动恢复.所有其他程序,YMMV.

丰田汽车就是一个很好的例子.说出你对油门电缆的看法,但它不是软件.

另见http://en.wikipedia.org/wiki/Therac-25

@Brian:好的软件会发现数据点是不连续的,并得出结论认为数据不好. (3认同)
@Brian:嗯,首先,你可以根据你的数据不好的知识采取纠正措施.例如,你可以停止加速. (3认同)

Answer 9

jak*_*om2 13

这是一个真正的问题,这就是ECC内存用于服务器和嵌入式系统的原因.为什么飞行系统不同于地面飞行系统.

例如,请注意,用于"嵌入式"应用程序的英特尔部件往往会在规格表中添加ECC.平板电脑的Bay Trail缺乏它,因为它会使内存更昂贵并且可能更慢.如果平板电脑每次在蓝色月亮中崩溃一个程序,用户就不会太在意了.无论如何,软件本身远不如硬件可靠.但对于打算用于工业机械和汽车的SKU,ECC是强制性的.从这里开始,我们期望SW更可靠,随机扰动的错误将是一个真正的问题.

经过IEC 61508和类似标准认证的系统通常都有启动测试,可以检查所有RAM是否正常工作(没有位卡在零或一个位置),以及运行时尝试从ECC检测到的错误中恢复的错误处理,以及通常还有内存擦除器任务经过并连续读写内存,以确保发生的任何错误都会被注意到.

但对于主流PC软件？没有大碍.对于长寿命的服务器？使用ECC和错误处理程序.如果无法纠正的错误导致内核崩溃,那就这样吧.或者你变得偏执并使用具有锁定步骤执行的冗余系统,这样如果一个核心被破坏,另一个核心可以在第一个核心重新启动时接管.

Answer 10

eri*_*len 11

我曾经编程这在太空中飞行,然后你的设备(据说,没有人曾经给我任何一篇关于它,但它被说成是在业务常识)可以预期的宇宙射线诱发错误所有的时间.

在大气层之上发生了两件事:1)总通量更高2)更多的是以沉重的,非常高能的粒子的形式出现(有足够的能量翻转一点点填充到一个小空间). (7认同)
关于参考文献，有书籍（例如，https://books.google.com/books?hl=en&lr=&id=Er5_rzW0q3MC）、会议（例如，http://www.radecs2015.org、http:// www.seemapld.org 等），以及有关此主题的大量论文。宇宙射线在航空航天领域可不是闹着玩的。它们是许多航天器使用抗辐射计算机的关键原因之一，其中大多数计算机具有现代智能烤箱的处理能力。 (2认同)

Answer 11

tob*_*xen 8

在这里的许多答案中,"宇宙射线事件"被认为具有均匀分布,这可能并非总是如此(即超新星).虽然根据定义(至少根据维基百科)的"宇宙射线"来自外太空,但我认为同样包括当地的太阳风暴(也就是在同一把伞下的日冕物质抛射)是公平的.我相信它可能导致几个位在短时间跨度,甚至可能破坏启用ECC的内存.

众所周知,太阳风暴会对电力系统造成相当大的破坏(如1989年3月的魁北克停电).计算机系统很可能也会受到影响.

大约10年前,我坐在另一个人的旁边,我们坐在我们的每台笔记本电脑上,这是一个充满"暴风雨"太阳天气的时期(坐在北极,我们可以间接地观察到这一点 - 很多北极光到可见).突然 - 在同一时刻 - 我们的笔记本电脑都崩溃了.他正在运行OS X,我正在运行Linux.我们都不习惯笔记本电脑崩溃 - 这在Linux和OS X上是一件非常罕见的事情.由于我们在不同的操作系统上运行,所以可以或多或少地排除常见的软件错误(并且它在飞跃过程中没有发生过第二).我把这个事件归结为"宇宙辐射".

后来,"宇宙辐射"已成为我职场的一个内部笑话.每当我们的服务器出现问题而我们找不到任何解释时,我们开玩笑地将故障归结为"宇宙辐射".:-)

Answer 12

Ric*_*ket 7

更常见的是,噪音可能会破坏数据.校验和用于在许多层面上对抗这种情况; 在数据电缆中,通常存在与数据一起行进的奇偶校验位.这大大降低了腐败的可能性.然后在解析级别时,通常忽略无意义数据,因此即使某些损坏确实超过了奇偶校验位或其他校验和,在大多数情况下也会被忽略.

此外,一些组件是电屏蔽的,以阻挡噪音(我猜可能不是宇宙射线).

但最后,正如其他回答者所说的那样,偶尔会有一些比特或字节被扰乱,而且无论这是否是一个重要的字节都是偶然的.最好的情况是,一个宇宙射线扰乱其中一个空位并且完全没有效果,或者使计算机崩溃(这是一件好事,因为计算机不会受到伤害); 但最坏的情况是,我相信你可以想象.

Answer 13

rep*_*vsd 5

我已经经历了这一点-宇宙射线翻转一点并不罕见，但是人们很少会观察到这一点。

2004年，我正在为安装程序开发一种压缩工具。我的测试数据是一些Adobe文件的解压缩量约为500 MB或更多。

经过乏味的压缩运行和解压缩运行以测试完整性之后，FC / B显示一个字节的差异。

MSB已在该字节内翻转。我也翻了个身，担心我有一个疯狂的错误，该错误只会在非常特定的条件下才会出现-我什至不知道从哪里开始寻找。

但是有件事告诉我要再次运行测试。我运行它并通过了。我设置了一个脚本来在一夜之间运行测试5次。早上，所有五个人都过去了。

所以那绝对是宇宙射线的翻转。

Answer 14

das*_*ndy 5

作为一个数据点，这恰好发生在我们的构建中：

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

Run Code Online (Sandbox Code Playgroud)

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

我不一定说这是“宇宙射线”，但症状相符。

归档时间：	15 年，6 月前
查看次数：	53278 次
最近记录：	7 年，11 月前