Amazonのデリバリープロバイダについて過去に以下の投稿をしましたが、私の地域を担当している「SBS即配サポート」というデリバリープロバイダについて、少し変更になっているようです。
wave.hatenablog.com
wave.hatenablog.com
NanoPi NEOの放熱と動作クロック
負荷と温度と動作クロックの一般論
PC、サーバー、スマートフォン等を高負荷状態で運用していると、CPU(というかSoC)の温度が上昇します。
こういった場面で一般的なPCやサーバーであれば、ファンの回転数が上昇するなどして、放熱効率を上げ温度上昇を抑える動きをします。が、NanoPi NEOを含めシングルボードコンピュータの多くや、スマートフォン等はファンレスであるために、高負荷状態が継続すれば温度は上昇する一方で、基本的には下がりません。
ですが、温度上昇が続けば最悪は周囲の可燃性の基盤やパーツを巻き込んで発火、そこまで至らずともデータシート上で担保された動作温度範囲外ではプロセッサが壊れる可能性が有ります。
そのような事態は製造業者もユーザもだれも望まないので、実際には動作クロックを低下させて発熱を抑えるという制御がかかることがほとんどです。
長時間使用でスマートフォンが過熱されてくると、動きが鈍くなる挙動を示しますが、これはCPUクロック、或いはGPUクロックを低下させて(さらにマルチコアプロセッサの場合は動作コア数を制限する場合もある)発熱を抑えているのです。
NanoPi NEOの場合
NanoPi NEOをARMBIANで運用している場合も、高温状態を検知するとプロセッサの動作クロックが落ちるようになっているようです。
デフォルトではガバナーにondemand(高負荷状況であれば動作クロックも速くし、低負荷なら動作クロックを下げる)が選択されていますが、一定温度以上になると動作クロック上限が制限されたような振る舞いを示します。
ですので、よほどの異常事態が起きない限りは高負荷状態を継続させても、発火するような事態には陥らないと考えられます(あくまでも個人的見解で、何らかの保証を確約するものではありません)。
パフォーマンス観点から要約すると、「熱いと最高動作クロックが制限(低下)されるため、本来の演算処理性能を発揮しない」ということになります。逆に、「適切に放熱すれば最高動作クロックの制限が発生しないため、本来の演算処理性能を発揮し続ける」と言えます。
実例
上記グラフは、日次で実行される夜間バッチ処理を実行している際、下記3パターンの放熱条件の場合の動作クロック(点線)とコア温度(実線)の関係をプロットしたものです。
| プロット色 | 放熱条件 |
|---|---|
| 水色(2018/07/03) | プラスチック板の上にNanoPi NEOを置いた状態(CPU表面がプラスチック板に接触しているか、プラスチック板との間隔が約1mm程度しかない状態)で運用 |
| オレンジ色(2018/07/10) | LANケーブルでNanoPi NEOを吊るした状態で運用 |
| 紫色(2018/07/17) | LANケーブルでNanoPi NEOを吊るしつつ、CPUに汎用ヒートシンクを貼り付けた状態で運用 |
処理データボリュームの変動による影響を抑えるため、いずれの放熱パターンも火曜日早朝からの時間帯をプロットしています。
このグラフからは以下の事が読み取れます。
- 単にプラスチック板の上に置いただけの状態が、最も高温状態(最高80度程度)となり、多くの時間帯で816MHzまで動作クロックが低下してしまう
- その結果、バッチ処理の終了時間が最も遅い
- LANケーブルで吊るした場合、CPU表面が外気に触れやすくなるためか、5度程度の温度低下が確認でき、CPUクロックの低下頻度も抑えられている
- その結果、バッチ処理が1時間程度短縮
- さらにヒートシンクを貼り付けた場合、外気接触面積が拡大するためか、さらに5度程度の温度低下が確認でき、CPUクロックもほぼ安定して960MHzを維持している
- その結果、さらにバッチ処理時間が短縮
※紫色の点線がバッチ処理終了後に急上昇しているのは、処理後にSCPによるアーカイブ処理を自動実行するように変更したため。