-
Notifications
You must be signed in to change notification settings - Fork 29
BlueGeneのエラー訂正の話
どうもL1にはECCをつけないのが一般的？ Parityチェックだけをして、エラーを検出、問題があったらL2を使って正しいデータを持ってくる、 EDC/ECCという方法が使われるらしい。その際、L1からL2、メモリはWrite throughとなる。 BlueGene/Lでは、このWrite throughが遅かったので、デフォルトでオフっていた可能性？
SC07におけるGordon Bell PrizeのWinnerはLivermore Teamの625億粒子の分子動力学計算であった。
-
論文 Extending Stability Beyond CPU Millennium A Micron-Scale Atomistic Simulation of Kelvin-Helmholtz Instability https://www.llnl.gov/sites/default/files/field/file/gordon_bell_journal.pdf
ちなみに著者の一人「Jim Glosli」が、仲間から「MPI Guy」と呼ばれている並列化のプロだった。
詳細は論文を読んでほしいが、論文のキモは並列化ではなく、エラー訂正にある。
BlueGene/LのL1のParityエラーの回避モードは二つ。 一つはWrite-through modeで、L1をL3やメインメモリに書き込むことで 汚染されていないデータと比較し、修正する方法。アプリケーション側は何もしなくて良いが、 パフォーマンスが落ちる。 もう一つは例外を飛ばす方法。これをアプリケーションがキャッチして適切な対応を取る。 Livermore teamがやったのはこれ。基本的には座標と運動量のバックアップをメモリにコピーして置いて、 例外を検知したら全ノードでバックアップした地点からやりなおす。 まぁ、素直な実装で、同じシステムを使うなら僕もそうすると思う。 システム任せの場合は20%程度性能が下がったが、メモリ上でのチェックポイントリスタートでは オーバーヘッドは1%以下になったとのこと。
https://pc.watch.impress.co.jp/docs/news/event/443999.html
我々の住む地球には日々宇宙線が飛んできている。ほとんどは上空で大気に弾かれるが、一部はそのまま地表まで飛んでくる。 その宇宙線がメモリモジュールの半導体に衝突して、例えばビット反転を引き起こす(実際には飛んできた陽子が大気とぶつかって中性子を作り、中性子線が別の原子にぶつかって荷電粒子を作り・・・ということが起きているらしい)。基本的にはそういうイベントが起きる可能性は低いのだが、実際に起きてしまうと 動作がおかしくなるので、だいたいのPCのメモリにはECC(エラー訂正回路)がついている。しかし、安いGPUなどでは、エラーが起きてもちょっと画像が乱れるだけなので、ECCのついていないメモリを使っていたりする。
さて、半導体の微細化に伴って、相対的に宇宙線の影響が大きくなってくる。そして、「ごく稀に」同じのメモリの二つのビットを同時にひっくり返すエラーを引き起こす。すると、ECCはエラーは検出できるが、修正はできない。通常、このような場合にはシステムはエラーを起こし、実行中のプログラムはクラッシュする。
さて、BlueGene/Lは、比較的「軽い」石を大量につなぐことでトータルの計算能力を稼ぐ設計思想を持っている。小さいノードが大量に束ねてあるので、メモリも大量に積んでいる。すると、普通は無視できる「宇宙線による訂正不可能なエラー」が、現実的な時間で起きてしまう。 BlueGeneはこの問題に対して二つのソリューションを提供している。