1つの中性子ヒットで、どのようにエラーが起こるかを見ると、長方形の領域でエラーが起こっているRectangular、直線状にエラーが起こっているLine、ばらばらに起こるRadom、1bitだけがエラーするSingleなどがある。なお、この図には描かれていないが、マトリクスの3次元の隣接領域にエラーが集中しているケースをCubicと分類している。
そして、各ベンチマークのエラーをこの5種のエラーパターンごとに分類したのが次の図である。色分けは上からCubic、Rectangular、Line、Single、Randomとなっている。ただし、各棒グラフにすべての分類が含まれているとは限らず、1つのパターンが大部分を占めているケースも多い。例えば、HotspotのDUEやLUDのDUEはSingleがほとんどであり、CLAMRやLUDのSDCはSquareが大部分、HotspotのSDCはLineが大部分とベンチマークごとに大きな違いがある。
DGEMMのSDCエラーはアルゴリズムベースのABFTを使えば、エラーパターンが青い〇で囲んだSingle、Line、Randomの場合は訂正が可能である。そうすると、エラー率は120FITから20FIT程度に改善できる。
エラービットの位置が大きくばらついているRectangularやCubicの場合は、SDCの検出を容易にする方法が知られている。このようなエラー検出を行えば、次の図の青〇で囲んだSDCは検出可能なエラーとなる。
また、すべてのSDCが致命的とは限らない。数値シミュレーションの結果は、多少の誤差が許容されることが多い。許容される誤差は正しい値から何%ずれているかという相対的な誤差が問題になる。
次のグラフは、横軸が許容誤差で、縦軸がFIT数の低減率である。青〇で囲んだ部分は、5%の誤差を許容した場合、FIT数がどれだけ減るかを示している。DGEMMやCLAMRではFIT数が70%程度小さくなる。しかし、Hotspotは5%の誤差を許容しても5%程度しかFIT数は低減していない。なお、この測定は、中性子ビームではなく、CAROL-FIというツールを使って、狙ったところにエラーを注入してその影響を評価している。
この実験では、5%程度の誤差を許容するとFIT数が半分以下になるアプリケーションが多いが、例外もあり、よく素性の分かっているアプリケーションでなければ、誤差を許容してエラーを減らすということは難しいように思われる。
次に、アプリケーションごとに、より詳しく分析した例を示す。LavaMDは注入したエラーの15%だけがSDCやDUEを引き起こしている。これは、他のアプリケーションと比べて低い比率である。詳しく調べると、電荷と距離のデータの配列と、制御変数のエラーがSDCやDUEを引き起こす場合が多いことが分かった。
この部分のエラー検出を強化するには54%のオーバヘッドを必要とするが、36%のエラーを検出することができたという。
次のグラフの横軸はプログラムの実行期間であり、縦軸はPVF(Program Vulnerability Factor)である。PVFはプログラムが持っている実行ステートの内、それぞれの時点で正しい実行を行うのに不可欠なステートの割合を示すものである。
アプリケーションの実行中、PVFで表されるエラーの影響度は、必ずしも一様ではない。LUDの場合は、実行の中盤でワークロードが高くなるが、この期間でのエラーの影響度は、他の期間の2倍から9倍となっている。これも興味深い情報であるが、これを利用してFIT数を低減するには、まだ、工夫が必要である。
これらの知見から、エラーの影響を軽減するABFTや2重化/3重化、エラー検出の選択的強化などの対策をとることができる。
LavaMDにはエラー検出の選択的強化を実装し、36%のエラーを検出できるようになった。強化対策の研究を続けており、2月にはより多くの結果を報告する予定であるという。
スパコンで計算を行っても、計算中にエラーが発生して、計算結果が使えないと、再計算が必要になる。そうなると、エラーが発生した計算に掛かったスパコンの計算時間はムダになってしまう。結果として、一定の時間の間に実行できる有効な計算量が減り、実効的なスパコンの計算性能が下がることになってしまう。
そして、スパコンの規模が大きくなると、エラーの頻度が上がるので、ますます、計算エラーとなる頻度が上がり、再計算が多くなって、加速度的に実行性能を低下させてしまう。
スパコンの発展を制限する2大要因は、消費電力とハードウェアエラーと言われており、エラー発生頻度とその対策の研究は、地味であるが、この点で非常に重要である。