4

NVIDIAのK10GPUでコードを実行しようとしています。5.0CUDAドライバーと4.2CUDAランタイムを使用しています。問題は、カーネルにかかる時間が反復とともに増加することです。各反復では、同じ数のソースとターゲット(またはパーティクル)が使用されます。このため、カーネルは最終的に非常に長い時間を要し、「GPUがバスから落ちた」などのランタイムエラーでコードがクラッシュします。

反復回数に応じてカーネル実行時間が増加する動作を示すプロットは、次のとおりです。

https://docs.google.com/open?id=0B5QLL4ig3LVqODdmVjNBTlp5UFU

ここでも同じことが起こるかどうかを理解するために、NVIDIAの「nbody」の例を実行しようとしましたが、そうです。パーティクル/ボディの数(Np)= 1e5および10回の反復の場合、コードは正常に実行されます。Np =1e5および反復=100、またはNp =1e6および反復=10の場合、コードはシステム全体をハングさせるモードになります。

Tesla C2050 NVIDIAカード(CUDAドライバーバージョン:3.2、ランタイムバージョン:3.2)を使用して別のマシンで自分のカーネルとNVIDIAのnbodyの例を実行すると、問題はなく、カーネルはすべての場合に同じ時間がかかります反復。

K10GPUを搭載したマシンで何が起こっているのかを理解しようとしています。このマシンでCUDAドライバーとランタイムバージョンのさまざまな組み合わせを試しましたが、次のようになります。

5.0 CUDAドライバー、4.2ランタイムの場合、ハングし、「GPUがバスから落ちた」と表示されることがあります。

4.2 CUDAドライバー、4.2ランタイムの場合、コード(nbodyと私のコード)が次のエラーでクラッシュします:「CUDAランタイムAPIエラー39:修正不可能なECCエラーが発生しました。」

5.0 CUDAドライバー、5.0ランタイムの場合、ハングし、「GPUがバスから落ちた」と表示されることがあります。

これは64ビットのLinuxマシンで、最近NVIDIAK10GPUカードを使用して組み立てました。gfortran44とgcc44を使用しています。

他に情報があれば教えてください。問題を追跡するために必要です。

助けてくれてありがとう!

M

4

1 に答える 1

4

この質問を閉じたと呼ぶことができるように、私はほとんど答えを作成しているだけですが、いくつかの詳細を追加しようとします。

Tesla GPUには、ファンのあるものとないものの2つの異なるカテゴリがあります。ファンを持っている人は(現時点では)「C」の指定がありますが、K20製品ファミリの名前は少し異なります。

これらは完全なリストではありません。

  1. ファン付きTeslaGPU:C870、C1060、C2050、C2070、C2075、K20c(「Cクラス」)
  2. ファンなしのTeslaGPU:M1060、M2050、M2070、M2075、M2090、K10、K20、K20X(「Mクラス」)

(現在、ファンまたは「C」の指定があるK10タイプの製品はありません)

ファン付きのTeslaGPUは、さまざまなワークステーションやサーバーのバリエーションを含む、さまざまなPCボックスやシャーシに接続できるように設計されています。彼らは独自のファンを持っているので、彼らは特定の温度レベルより低い入口空気の供給を必要とします、しかしそれを考えると、彼らは彼ら自身を涼しく保ちます。作業負荷が増加し、発生する熱が増加すると、ファンは自分のファンを回転させて涼しく保ちます。このプロセスを台無しにする主な方法は、吸気の流れを制限するか、最大吸気仕様よりも高温の周囲空気環境に置くことです。

ファンのないTeslaGPUにはパッシブヒートシンクと呼ばれるものがあり、独立して冷却してパッシブにすることはできません冷却プロセスにおける役割。彼らはまだ温度センサーを持っていますが、この温度センサーを監視するのはサーバーBMC(ベースボード管理コントローラー)の責任になります(これは、OSやGPUに向けられたアクティビティに関係なく、ハードウェア/ファームウェアレベルで直接行われます) )、および指定された温度に基づいてカードを冷却するのに十分なレベルの空気の流れをカードに向けます。BMCは、GPU上のエアフローを制御するサーバーシャ​​ーシに設計されているファンを増やすことでこれを実現します。通常、このプロセスを支援するために、シャーシ内にシュラウド/ダクトがあります。これらのカードを統合するサーバーメーカーにはさまざまな責任があり、これを機能させるにはNVIDIAのさまざまな技術仕様に従う必要があります。

ファンなしでTeslaGPUを手に入れ、ランダムなシャーシでそれを叩くだけの場合、この質問で説明されている動作をすることがほぼ保証されます。このため、Teslaの「M」シリーズおよび「K」シリーズのGPUは通常、認定プロセスを経たOEMにのみ販売されます。

平均的なシステム管理者/システムアセンブラは、適切な閉ループファン制御システムを考案する可能性が低く、通常、温度センサーとアクセス方法を定義する必要な仕様に簡単にアクセスできないため、これらのいずれかを使用している場合の唯一のクルージー回避策単に遊んでいなければならないのは、どのような設定であっても、カード上に高レベルの連続的な気流を向けることです。これはノイズが多い可能性が高いことに注意してください。ノイズの多いレベルのエアフローがない場合は、ワークロードが高い状況でカードを冷却するのに十分なエアフローがない可能性があります。さらに、GPUの温度にも注意を払う必要があります。に注意してくださいnvidia-smiGPUの温度を監視する方法は、すべてのMクラスGPU(つまり、ファンのないGPU)では機能しません。残念ながら、Fermi以前のMクラスGPU(CクラスGPUとは異なる)の温度センサーアクセスの方法は、nvidia-smiコマンドを介してシステム内で簡単に監視できないため、これらの場合はnvidia-smiから温度の読み取り値を取得しないため、このアプローチの管理はさらに困難になります。Keplerの世代で状況が変わったため、nvidia-smiメソッドとサーバーBMCの両方でハードウェア/ファームウェアレベルで温度を監視できるようになりました。

ファン付きのCクラス製品は、世代に関係なく、nvidia-smiで監視できる温度を備えています。ただし、カードには独自の制御システムがあり、カード自体を冷却するため、通常はこれは必要ありません。

コメントで述べたように、すべてのGPUにはさまざまな保護メカニズムもありますが、いずれも損傷を防ぐことが保証されていません。(カードを火に投げ込んだ場合、それについては何もする必要はありません。)しかし、最初の典型的なメカニズムは熱スロットリングです。GPUの最大安全動作範囲に近い事前定義された高温では、GPUファームウェアは独立してクロックを減らし、それ以上の温度上昇を防ぎます。(カードのクロックが遅いと、一般的に熱を発生する能力も多少低下します。)これは大雑把なメカニズムであり、この熱スロットリングが発生すると、冷却領域に何かがすでに存在します。間違い。このカードは、通常の動作条件下では、熱スロットリングに入らないように設計されています。温度が上昇し続ける場合(そしてこの時点でヘッドルームがあまりない場合)、カードはそれ自体を停止する最終的な保護モードに入ります。この時点で、GPUはシステムに応答しなくなり、OSレベルでは、「gpuがバスから落ちました」などのメッセージが一般的です。これは、冷却が失敗し、保護メカニズムが失敗したことを意味します。

于 2012-12-13T03:22:19.910 に答える