もう一度、私は設計レビューに参加し、特定のシナリオの確率がプログラムに影響を与える「宇宙線のリスクよりも低い」という主張に遭遇しました。確率はです。
「2-128は340282366920938463463374607431768211456の1つなので、これらの計算が数十億倍ずれていても、ここでチャンスをつかむことは正当だと思います。私たちを台無しにする、と私は信じています。」
このプログラマーは正しいですか？宇宙線がコンピューターに当たってプログラムの実行に影響を与える確率はどれくらいですか？
ウィキペディアから：
1990年代のIBMの調査によると、コンピューターでは通常、1か月あたり256メガバイトのRAMごとに約1つの宇宙線によるエラーが発生します。[15]
これは、1か月あたり1バイトあたり3.7×10 -9 、または1秒あたり1バイトあたり1.4× 10-15の確率を意味します。プログラムが1分間実行され、20 MBのRAMを占有している場合、失敗の確率は次のようになります。
60 × 20 × 1024²
1 - (1 - 1.4e-15) = 1.8e-6 a.k.a. "5 nines"
エラーチェックは、失敗の余波を減らすのに役立ちます。また、ジョーがコメントしたようにチップのサイズがよりコンパクトであるため、故障率は20年前とは異なる可能性があります。
どうやら、重要ではありません。このニューサイエンティストの記事から、インテルの特許出願からの引用：
「宇宙線によって引き起こされるコンピューターのクラッシュが発生し、デバイス（トランジスタなど）のチップのサイズが小さくなるにつれて、周波数とともに増加すると予想されます。この問題は、今後10年間でコンピューターの信頼性を大きく制限するものになると予測されています。」
あなたはここで完全な特許を読むことができます。
注：この回答は物理に関するものではなく、ECC以外のメモリモジュールでのサイレントメモリエラーに関するものです。一部のエラーは宇宙空間から発生する可能性があり、一部のエラーはデスクトップの内部空間から発生する可能性があります。
CERNクラスターやGoogleデータセンターなどの大規模サーバーファームでのECCメモリ障害に関するいくつかの研究があります。ECCを備えたサーバークラスのハードウェアは、すべてのシングルビットエラーを検出して修正し、多くのマルチビットエラーを検出できます。
非ECCデスクトップ（および非ECCモバイルスマートフォン）が多数あると想定できます。論文でECC修正可能なエラー率（シングルビットフリップ）を確認すると、ECC以外のメモリでのサイレントメモリの破損率を知ることができます。
大規模なCERN2007の調査「データの整合性」：ベンダーは、「 メモリモジュールのビットエラーレートは10 -12」、「観測されたエラーレートは予想よりも4桁低い」と宣言しています。データ集約型タスク（8 GB / sのメモリ読み取り）の場合、これは、シングルビットフリップが毎分（10 -12ベンダーBER）または2日に1回（10 -16 BER）発生する可能性があることを意味します。
2009年のGoogleの論文「DRAMErrorsinthe Wild：A Large-Scale Field Study」によると、1 Mビットあたり最大25000〜75000の1ビットFIT（10億時間あたりの時間の障害）が発生する可能性があります。これは1〜5ビットに相当します。計算後の8GBのRAMの1時間あたりのエラー。紙は同じことを言っています：「1GBあたり年間2000-6000の修正可能なエラー率を意味します」。
2012 Sandiaレポート「大規模ハイパフォーマンスコンピューティングのためのサイレントデータ破損の検出と修正」：「ダブルビットフリップは起こりそうにないと考えられました」が、ORNLの高密度Cray XT5では、「75,000以上のDIMMで1日1回の割合で」 ECCを使用します。そして、シングルビットエラーはもっと高くなるはずです。
したがって、プログラムに大きなデータセット（数GB）がある場合、またはメモリの読み取りまたは書き込み速度が高い（GB /秒以上）場合、数時間実行すると、デスクトップハードウェアで最大数回のサイレントビットフリップが予想されます。このレートはmemtestでは検出できず、DRAMモジュールは良好です。
BOINCインターネット全体のグリッドコンピューティングのように、何千もの非ECC PCで実行される長いクラスターには、常にメモリビットフリップやディスクおよびネットワークのサイレントエラーによるエラーが発生します。
また、Sandiaの2012年のレポートに見られるように、シングルビットエラーからのECC保護を備えた大規模なマシン（1万台のサーバー）の場合、毎日ダブルビットフリップが発生する可能性があるため、フルサイズの並列を実行する機会はありません。数日間のプログラム（定期的なチェックポイントなし、および二重エラーの場合の最後の適切なチェックポイントからの再起動なし）。巨大なマシンは、すべてがECCによって保護されているわけではないため、キャッシュとCPUレジスタ（アーキテクチャと内部チップの両方のトリガー、たとえばALUデータパス）でもビットフリップを取得します。
PS：DRAMモジュールが不良の場合、事態はさらに悪化します。たとえば、ラップトップに新しいDRAMをインストールしましたが、数週間後に死亡しました。それは多くのメモリエラーを出し始めました。私が得たもの：ラップトップがハングし、Linuxが再起動し、fsckを実行し、ルートファイルシステムでエラーを見つけ、エラーを修正した後に再起動したいと言っています。しかし、次回の再起動のたびに（私はそれらのうちの約5〜6を実行しました）、ルートファイルシステムでまだエラーが見つかりました。
さて、宇宙線がトヨタ車の電子機器を誤動作させたようですので、確率は非常に高いと思います:)
ウィキペディアは、90年代のIBMによる研究を引用しており、「コンピューターは通常、1か月あたり256メガバイトのRAMごとに約1つの宇宙線によるエラーを経験します」と示唆しています。残念ながら、引用はScientific Americanの記事に対するものであり、それ以上の参照はありませんでした。個人的には、その数は非常に多いと思いますが、おそらく宇宙線によって引き起こされるほとんどのメモリエラーは、実際の問題や目立った問題を引き起こしません。
一方、ソフトウェアシナリオに関して確率について話している人は、通常、何について話しているのかわかりません。
ECCを使用すると、宇宙線の1ビットエラーを修正できます。宇宙線が2ビットエラーを引き起こすケースの10％を回避するために、ECCセルは通常、チップ上でインターリーブされるため、2つのセルが隣り合っていません。したがって、2つのセルに影響を与える宇宙線イベントは、2つの修正可能な1ビットエラーになります。
サンの状態:(部品番号816-5053-2002年4月10日）
一般的に、宇宙線のソフトエラーはDRAMメモリで約10〜100 FIT / MBの割合で発生します（1 FIT = 1デバイスが10億時間で故障します）。したがって、10 GBのメモリを備えたシステムは1,000〜10,000時間ごとにECCイベントを表示し、100GBを備えたシステムは100〜1,000時間ごとにイベントを表示する必要があります。ただし、これは大まかな見積もりであり、上記の効果の関数として変化します。
メモリエラーは実際のものであり、ECCメモリが役立ちます。正しく実装されたECCメモリは、シングルビットエラーを修正し、ダブルビットエラーを検出します（このようなエラーが検出された場合、システムを停止します）。これは、Memtest86と悪いメモリを発見する。もちろん、宇宙線によって引き起こされる一時的な障害は、一貫して障害が発生しているメモリとは異なりますが、メモリが正しく動作するためにどれだけ信頼すべきかというより広い問題に関連しています。
20 MBの常駐サイズに基づく分析は、些細なアプリケーションには適切かもしれませんが、大規模なシステムには、通常、大規模なメインメモリを備えた複数のサーバーがあります。
興味深いリンク：http ：//cr.yp.to/hardware/ecc.html
残念ながら、このページのCorsairリンクは機能していないようです。代わりに、ここでCorsairリンクを表示してください。
これは実際の問題であり、ECCメモリがサーバーや組み込みシステムで使用される理由です。そして、なぜ飛行システムが地上ベースのものと異なるのか。
たとえば、「組み込み」アプリケーション向けのIntel部品は、スペックシートにECCを追加する傾向があることに注意してください。タブレット用のベイトレイルには、メモリが少し高価になり、場合によっては遅くなるため、これが欠けています。また、タブレットが青い月に1回ずつプログラムをクラッシュさせた場合、ユーザーはあまり気にしません。とにかく、ソフトウェア自体はHWよりもはるかに信頼性が低くなります。ただし、産業機械および自動車での使用を目的としたSKUの場合、ECCは必須です。ここから、SWの信頼性が大幅に向上することが期待され、ランダムな不調によるエラーが実際の問題になります。
IEC 61508および同様の規格に認定されたシステムには、通常、すべてのRAMが機能している（ビットが0または1にスタックしていない）ことを確認する起動テストと、ECCによって検出されたエラーから回復しようとする実行時のエラー処理の両方があります。多くの場合、発生したエラーに気付くようにメモリを継続的に読み書きするメモリスクラバータスクもあります。
しかし、主流のPCソフトウェアの場合はどうでしょうか。大したことではありません。寿命の長いサーバーの場合は？ECCとフォールトハンドラーを使用します。修正不可能なエラーがカーネルを強制終了する場合は、そうしてください。または、偏執的になり、ロックステップ実行の冗長システムを使用して、一方のコアが破損した場合に、最初のコアの再起動中にもう一方のコアが引き継ぐことができるようにします。
プログラムが生命にかかわる場合（失敗すると誰かを殺す）、フェイルセーフになるか、そのような失敗から自動的に回復するようにプログラムを作成する必要があります。他のすべてのプログラム、YMMV。
トヨタはその好例です。スロットルケーブルについてどう思うか言ってください、しかしそれはソフトウェアではありません。
私はかつて宇宙を飛ぶ装置をプログラムしましたが、それからあなた（おそらく誰も私にそれについての論文を見せてくれませんでしたが、それはビジネスの常識であると言われていました）は宇宙線が常にエラーを引き起こすことを期待できました。
「宇宙線イベント」は、ここでの回答の多くで均一に分布していると見なされますが、これは常に正しいとは限りません（つまり超新星）。定義上（少なくともウィキペディアによると）「宇宙線」は宇宙から来ていますが、同じ傘の下に局所的な太陽嵐（別名コロナ質量放出）も含めるのは公平だと思います。短い時間内に数ビットが反転する可能性があり、ECC対応メモリでさえも破損する可能性があると思います。
太陽嵐が電気システムにかなりの大混乱を引き起こす可能性があることはよく知られています（1989年3月のケベックの停電など）。コンピュータシステムも影響を受ける可能性が非常に高いです。
約10年前、私は別の男の隣に座っていました。私たちはそれぞれのラップトップを持って座っていました。それはかなり「嵐の」太陽の天気の時期でした（北極に座って、これを間接的に観察することができました-たくさんのオーロラ見られる）。突然、まったく同じ瞬間に、両方のラップトップがクラッシュしました。彼はOSXを実行していて、私はLinuxを実行していました。どちらもラップトップのクラッシュに慣れていません。LinuxとOSXでは非常にまれなことです。異なるOSで実行していたため、一般的なソフトウェアのバグはほぼ除外できます（うるう秒の間に発生しませんでした）。 2番目）。私はその出来事を「宇宙線」に帰するようになりました。
その後、「宇宙線」は私の職場の内面の冗談になりました。私たちのサーバーで何かが起こって、それについての説明が見つからないときはいつでも、私たちは冗談めかしてその障害を「宇宙線」に帰します。:-)
多くの場合、ノイズによってデータが破損する可能性があります。チェックサムは、多くのレベルでこれに対抗するために使用されます。データケーブルには通常、データと一緒に移動するパリティビットがあります。これにより、破損の可能性が大幅に減少します。次に、解析レベルでは、ナンセンスデータは通常無視されるため、一部の破損がパリティビットまたは他のチェックサムを通過した場合でも、ほとんどの場合無視されます。
また、一部のコンポーネントは、ノイズを遮断するために電気的にシールドされています（おそらく宇宙線ではないと思います）。
しかし、結局、他の回答者が言ったように、スクランブルされるビットまたはバイトが時折あり、それが重要なバイトであるかどうかは偶然に任されています。最良のシナリオでは、宇宙線が空のビットの1つをスクランブルし、まったく効果がないか、コンピューターをクラッシュさせます（コンピューターが害を及ぼすのを防ぐため、これは良いことです）。しかし、最悪の場合、まあ、あなたは想像できると確信しています。
私はこれを経験しました-宇宙線が1ビット反転することは珍しいことではありませんが、人がこれを観察することはほとんどありません。
私は2004年にインストーラー用の圧縮ツールに取り組んでいました。私のテストデータは、約500MB以上の解凍されたAdobeインストールファイルでした。
面倒な圧縮実行と、整合性をテストするための解凍実行の後、FC/Bは1バイト異なることを示しました。
その1バイト内で、MSBが反転しました。私はまた、非常に特定の条件下でのみ表面化するクレイジーなバグがあるのではないかと心配して、ひっくり返しました。どこから探し始めればよいのかさえわかりませんでした。
しかし、何かが私にテストをもう一度実行するように言った。私はそれを実行し、それは合格しました。テストを一晩で5回実行するスクリプトを設定しました。朝、5人全員が過ぎました。
だから、それは間違いなく宇宙線のビットフリップでした。
フォールトトレラントハードウェアも確認することをお勧めします。
たとえば、Stratus Technologyは、計算結果を比較して、ロックステップに2つまたは3つの「メインボード」を備えたftServerと呼ばれるWintelサーバーを構築します。（これは宇宙船でも行われることがあります）。
Stratusサーバーは、カスタムチップセットからバックプレーンのロックステップに進化しました。
非常によく似た（ただしソフトウェアの）システムは、ハイパーバイザーに基づくVMWareフォールトトレランスロックステップです。
データポイントとして、これはビルドで発生しました。
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 - ^
これは、たまたまソースファイルの非常に重要な場所で、コンパイル中に発生するビットフリップのように非常に強く見えます。
必ずしも「宇宙線」と言っているわけではありませんが、症状は一致しています。