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