Titan GPUの2ビットエラーは毎週1回程度
結果として問題になるハードウェアエラーはECCで訂正できない2ビットエラーであるが、このエラーの頻度は平均すると週に1回程度で、TitanのGPUの信頼度は非常に高いと言える(約2万GPUで週に1回のエラーは、1個のMTBFが300万時間、故障率は30fit程度という計算になる)。
左は、2ビットエラーの月間の発生頻度。平均すると1回/週程度で、GPUのMTBFは非常に高い。Off the Busエラーは現在では、ほとんど発生していない。また、DPRエラーはアプリをクラッシュさせないエラーである (これ以降の図は、SC15での発表スライドを撮影したもの) |
2ビットエラーの発生がどの場所で起こっているかを調べたものが、次の図である。Titanシステムは1列に25キャビネット並んでおり、それが8列あるという構成になっており、左の図は、それぞれの赤丸がキャビネットに対応している。そして丸の大きさが、エラーの発生回数に対応している。この図を見ると、2ビットエラーの発生は一様ではなく、発生頻度が高いキャビネットがある一方、まったく発生していないキャビネットもあることが分かる。
Titanのキャビネットの中には8枚のブレードを収容するケージという単位があり、キャビネットにはケージが3段に積まれて収容されている。2番目のグラフはケージの位置ごとの2ビットエラーの発生回数を示したもので、上に積まれたケージの方がエラー回数が多い。キャビネット内は下から冷風を吹き上げるという方法で冷却されており、上に積まれたケージの方が約5℃温度が高くなる。従って、このケージ位置に対するエラー回数の傾向は、温度依存性の可能性がある。
3番目のグラフは同じGPUカードのエラーは1回と数え、何個のGPUがエラーしたかを数えたもので、こちらの方がケージ位置依存性が強くなっている
次のグラフは、GPUの中のどの部分でエラーが発生したかを示すものである。左は2ビットエラーの発生を示すもので、デバイスメモリ(GDDR5 DRAM)が86%、レジスタファイルが14%で、L1キャッシュ、L2キャッシュ、テクスチャメモリではエラーは発生していない。
GDDR5 DRAMは6GBと容量が大きいので、エラー発生が多いのは当然である。レジスタファイルは合計すると3.5MBであり2番目に容量の大きいアレイであるが、デバイスメモリと比較して、容量の割には2ビットエラーの頻度が高い。論文では、レジスタファイルはカラムインタリーブが適切でないなどの設計上の問題があるのではないかと推測している。
1ビットエラーの分析
右側のグラフは1ビットエラーの発生比率を示すもので、98%がL2キャッシュで発生し、2%がデバイスメモリとなっている。1ビットエラーの大部分を占めるL2キャッシュで、2ビットエラーがほとんど発生しないというこの結果は不思議で、筆者には、なぜ、このような比率になるのかは理解できない。論文も読んでみたのであるが、1ビットエラーの分析は論文には書かれておらず、スライド発表にしか含まれていない。
2ビットエラーの86%はデバイスメモリで発生している。そして残りの14%はRegister Fileで発生している。一方、1ビットエラーの98%はL2キャッシュで発生し、2%がデバイスメモリで発生している |
1ビットエラーはECCで訂正されてしまうので、直接、プログラムの動作には影響はないが、DPRエラーの原因になる。また、1ビットエラーの発生状況は、全体のエラー耐性の目安になる。
全部の1ビットエラーの発生をキャビネットごとに示したものが次の左端の図である。これを見ると、1ビットエラーの発生は非常に偏っている。しかし、エラーの多い上位10枚のGPUを除いた中央の図ではかなり一様に近づき、上位50枚のGPUを除いた右端の図では、1ビットエラーの発生はほぼ一様になっている。 つまり、1ビットエラーを起こしやすいGPUが18,688枚の中に50枚程度含まれているが、それらを除けば、1ビットエラーはほぼ一様に発生しているというわけである。
キャビネットごとの1ビットエラーの発生状況。左から、全GPUカードのデータ、1ビットエラーの多い上位10GPUを除いたデータ、上位50GPUを除いたデータ。上位50GPUを除けば、ほぼ一様のエラー発生となっている |
次の図の上のグラフは、1ビットエラーの発生頻度をケージ位置ごとにまとめたグラフである。1ビットエラーの発生回数は、全GPU使用の場合は上の2つのケージでの発生が多く、一番下のケージでの発生が少ない。しかし、エラーの多い上位50GPUを除いた右端の図では、ケージ位置による違いは殆ど見られない。
下の図は1回でもエラーしたGPU枚数のグラフで、全GPUで見ても、エラー回数の多い、10GPU、50GPUを除外してもあまりグラフの形は変わらない。
結論
結論として、巨大なGPUシステムのエラー特性は、まだ、良く分かっていない。GPUのエラーを解析するためには、正しい方法論、安定性の高い実験フレームワークを開発して間違いを起こさないようにすることが重要である。GPUのエラーを監視するツールは改良されてきたが、より多くのデータが得られるように改良する必要がある。
この論文では、GPUエラー発生の空間的、時間的な分布、アーキテクチャに直結したエラーの性質、エラーの伝播、GPUの使用率とエラーの相関を分析し、考察を行った(著者注:本レポートでは主にエラーの空間的な分布だけをカバーしており、他の結果については原著の論文を参照戴きたい)。
この結果は、他のデータセンターの運用効率の改善、信頼性モデルやシミュレーションの精度の改善と将来のGPUアーキテクチャの設計に役立つものである。
最初に掲げたCheckpoint作成の効率化に対する改善には直接は触れられていないが、2億8000万デバイス時間もの膨大なログを分析してGPUエラーの発生状況を明らかにしたことは大きな功績である。特に、NVIDIAのK20X GPUの大量運用時の故障モードや故障頻度が明らかにされたことは、将来のGPUシステムを設計するにあたって重要な参考データとなる。