宇宙線：プログラムに影響を与える確率はどれくらいですか？

もう一度私はデザインレビューを行っていて、特定のシナリオの確率がプログラムに影響を与える「宇宙線のリスクよりも低い」という主張に遭遇しました。確率です。

「2 ^-128は340282366920938463463374607431768211456のうちの1 つなので、これらの計算が数十億分の1の係数でずれていても、ここでチャンスを利用することは正当化できると思います...私たちを台無しにすると私は信じています。」

このプログラマは正しいですか？宇宙線がコンピュータに当たり、プログラムの実行に影響を与える確率はどのくらいですか？

ウィキペディアから：

1990年代のIBMの調査によると、コンピューターは通常、1か月あたり256メガバイトのRAMあたり約1つの宇宙線誘発エラーを経験します。^[15]

これは、3.7×10 ^-9の確率を意味します 1か月あたり1バイトあたり、または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"

エラーチェックは、失敗の余波を減らすのに役立ちます。また、Joeのコメントによると、チップのサイズがよりコンパクトになるため、故障率は20年前とは異なる可能性があります。

どうやら、重要ではありません。このニュー・サイエンティストの記事、インテルの特許出願からの引用：

「宇宙線によって引き起こされるコンピューターのクラッシュが発生しており、デバイス（たとえば、トランジスター）のチップサイズが小さくなるにつれて、周波数とともに増加すると予想されます。この問題は、今後10年間でコンピューターの信頼性の主要な制限になると予測されています。」

あなたはここで完全な特許を読むことができます。

注：この回答は物理学に関するものではなく、ECC以外のメモリモジュールでのサイレントメモリエラーに関するものです。エラーの一部は外部空間から発生する場合があり、一部はデスクトップの内部空間から発生する場合があります。

CERNクラスターやGoogleデータセンターなどの大規模サーバーファームでのECCメモリ障害に関するいくつかの調査があります。ECCを備えたサーバークラスのハードウェアは、すべてのシングルビットエラーを検出して修正し、多くのマルチビットエラーを検出できます。

非ECCデスクトップ（および非ECCモバイル・スマートフォン）が多数あると想定できます。ECC修正可能なエラー率（単一のビットフリップ）についてペーパーをチェックすると、非ECCメモリでのサイレントメモリ破損率を知ることができます。

• 大規模なCERN 2007調査「データの整合性」：ベンダーは「 メモリモジュールのビットエラーレートが10 ^-12である」と宣言し、「観測されたエラーレートは予想よりも4桁低い」としています。データ集約型のタスク（8 GB /秒のメモリ読み取り）の場合、これは、1ビットのフリップが毎分（10 ^-12ベンダーのBER）または2日に1回（10 ^-16 BER）発生する可能性があることを意味します。

• 2009年のGoogleの論文「DRAM Errors in the Wild：A Large-scale Field Study」によると、1ビットあたり最大25000〜75000の1ビットFIT（10億時間あたりの時間の失敗）があり、1〜5ビットに相当するとのことです計算後、8 GBのRAMの1時間あたりのエラー。紙は同じことを言っています：「平均してGBあたり年間2000〜6000の修正可能なエラー率」。

• 2012年のサンディアのレポート「大規模な高性能コンピューティングのためのサイレントデータ破損の検出と修正」：「ダブルビットフリップは考えられない」とされましたECC付き。そして、シングルビットエラーはより高くなるはずです。

そのため、プログラムに大きなデータセット（数GB）があるか、メモリの読み取りまたは書き込み速度（GB / s以上）が高く、数時間実行される場合、デスクトップハードウェアで最大数回のサイレントビットフリップが予想されます。この速度はmemtestでは検出できず、DRAMモジュールは良好です。

BOINCのインターネット全体のグリッドコンピューティングのように、ECC以外の何千ものPCで長いクラスターを実行すると、常にメモリのビットフリップからのエラーと、ディスクおよびネットワークのサイレントエラーからのエラーが発生します。

そして、より大きなマシン（1万台のサーバー）の場合、シングルビットエラーからのECC保護があっても、Sandiaの2012年のレポートに見られるように、ダブルビットフリップが毎日発生する可能性があるため、フルサイズのパラレルを実行する機会はありません数日間のプログラム（定期的なチェックポイントと、二重エラーの場合は最後の適切なチェックポイントからの再起動なし）。巨大なマシンは、それらのすべてがECCで保護されているわけではないため、キャッシュとCPUレジスタ（アーキテクチャチップと内部チップの両方のトリガーなど）でビットフリップを取得します。

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-10 2002年4月）

一般的に言えば、宇宙線ソフトエラーは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と障害ハンドラーを使用します。修正不可能なエラーがカーネルを殺すなら、そうしてください。または、偏執狂に陥り、ロックステップ実行を備えた冗長システムを使用して、一方のコアが破損した場合に、最初のコアが再起動する間にもう一方のコアが引き継ぐことができます。

プログラムが生命にかかわる（失敗すると誰かを殺す）場合は、フェイルセーフになるか、そのような失敗から自動的に回復するようにプログラムを記述する必要があります。他のすべてのプログラム、YMMV。

トヨタがその好例です。あなたがスロットルケーブルについて何をするか言うが、それはソフトウェアではありません。

http://en.wikipedia.org/wiki/Therac-25も参照してください

私はかつて宇宙を飛ぶことになるデバイスをプログラムしましたが、あなたは（おそらく、誰もそれについて私に紙を見せたことはなかったでしょうが、ビジネスの常識であると言われていました）宇宙線は常にエラーを引き起こすと期待できます。

「宇宙線事象」は、ここでの答えの多くで均一な分布を持っていると考えられます、これは常に真であるとは限りません（すなわち、超新星）。定義による「宇宙線」（少なくともWikipediaによると）は宇宙空間からのものですが、局所的な太陽嵐（別名コロナ質量放出）も含めるのは公平だと思います同じ傘の下での。短いタイムスパン、ECC対応のメモリを破壊するのに十分な可能性があります。

太陽嵐が電気システムにかなりの混乱を引き起こす可能性があることはよく知られています（1989年3月のケベックの停電など））。コンピュータシステムも影響を受ける可能性が高いです。

約10年前、私は別の男の隣に座っていました。それぞれのラップトップで座っていました。それは、非常に「嵐」の太陽天気の時期でした（北極圏に座って、これを間接的に観測できました-オーロラの多くが見られる）。突然-同じ瞬間に-両方のノートパソコンがクラッシュしました。彼はOS Xを実行しており、私はLinuxを実行していました。どちらもラップトップのクラッシュに慣れていません。これは、LinuxとOS Xでは非常にまれなことです。異なるOSで実行していたため、一般的なソフトウェアのバグはほぼ除外される可能性があります（また、うるう時は発生しませんでした）第二）。私はその出来事を「宇宙放射線」に帰するようになりました。

その後、「宇宙放射線」は職場の冗談になりました。私たちのサーバーで何かが起こり、その説明が見つからないときはいつでも、私たちは冗談でその障害を「宇宙放射線」に帰します。:-)

多くの場合、ノイズはデータを破壊する可能性があります。チェックサムは多くのレベルでこれに対抗するために使用されます。データケーブルには、通常、データと一緒に移動するパリティビットがあります。これは非常ににより、破損の可能性が減少します。その後、解析レベルでは、ナンセンスデータは通常無視されます。そのため、一部の破損がパリティビットや他のチェックサムを通過した場合でも、ほとんどの場合は無視されます。

また、一部のコンポーネントはノイズを遮断するために電気的にシールドされています（おそらく宇宙線ではないと思います）。

しかし、結局、他の回答者が言ったように、スクランブルされるビットまたはバイトが時々あり、それが重要なバイトであるかどうかは偶然に任されています。最良のシナリオでは、宇宙線が空のビットの1つをスクランブルしてまったく影響を与えないか、コンピューターをクラッシュさせます（コンピューターに害を与えないため、これは良いことです）。でも最悪の場合は、想像できると思います。

私はこれを経験しました-宇宙線が1ビット反転することはまれではありませんが、人がこれを観察することはほとんどありません。

私は2004年にインストーラーの圧縮ツールに取り組んでいました。私のテストデータは、約500 MB以上のAdobeインストールファイルを解凍したものです。

面倒な圧縮の実行、および完全性をテストするための解凍の実行後、FC / Bは1バイトの違いを示しました。

その1バイト内で、MSBが反転しました。私はまた反転し、非常に特定の条件下でのみ表面化するクレイジーなバグがあるのではないかと心配しました。

しかし、何かが私にもう一度テストを実行するように言いました。私はそれを実行し、それは合格しました。夜間に5回テストを実行するスクリプトを設定しました。朝は５人全員が過ぎた。

それは間違いなく宇宙線のビットフリップでした。

フォールトトレラントハードウェアも確認することをお勧めします。

たとえば、Stratus Technologyは、ftServerと呼ばれる2つまたは3つの「メインボード」がロックステップにある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  - ^

ソースファイルの非常に重要な場所で偶然にコンパイル中にビットフリップが発生しているように見えます。

これは必ずしも「宇宙線」と言っているわけではありませんが、症状は一致しています。