ファンのヒステリシスは、常時稼働するホームサーバーのファンノイズをどのように低減するのですか？

ファンのヒステリシスは、常時稼働のホームサーバーが同じファン曲線の閾値を何度も越えるときにノイズを減らします。温度が1度逆転するたびにファン速度を上げ下げする代わりに、コントローラーは別の戻り閾値を越えるまで待ちます。これにより、ファンハンティングと呼ばれる速い-遅い-速いのサイクルが断ち切られ、より安定して目立たない音になります。

ヒステリシスは不要な速度切り替えの問題にのみ有効です。特定のRPMでファンを静かにしたり、熱を除去したり、摩耗したベアリングを修理したり、空気の流れの妨げを補ったりはしません。実際の目的は冷却をできるだけ遅らせることではなく、短時間の温度変動が可聴反応を引き起こすのを防ぎつつ、持続的な熱には迅速に対応することです。

なぜ常時稼働のホームサーバーは「ファンハンティング」を始めるのか

一見アイドル状態のホームサーバーでも短時間のジョブを実行しています。メディアライブラリが新しいファイルをスキャンしたり、コンテナが再起動したり、バックアップがチェックサムを計算したり、ファイルシステムがデータをフラッシュしたり、OSがメンテナンスを行ったりします。これらのタスクは1～2個のCPUコアを数秒間ブースト状態にしますが、シャーシ温度の持続的な上昇は引き起こしません。

CPUパッケージセンサーはヒートシンク、ケース内空気、ストレージベイ、マザーボードよりもはるかに速く反応します。ファンが生のパッケージ温度の読み取りに従うと、短いスパイクが曲線のポイントを超え、追加の気流が熱源に実質的な影響を与える前に高いRPMを命じることがあります。温度平均化とファン曲線ヒステリシスに関するOEMのガイダンスでは、CPUのホットスポットは数分の一秒単位で変動し、別々の上昇・下降閾値がファンステップ付近での頻繁な切り替えを防ぐと述べられています。

サーバーの通常温度がそのステップ付近にあると、ノイズが繰り返されます。コントローラーは49°Cで30％のファン負荷を要求し、50°Cで45％に上げるかもしれません。負荷によりセンサーが50°Cに達し、ファンが加速し、読み取り値が49°Cに戻るとファンは再び減速します。別のバックグラウンドの負荷がこのシーケンスを繰り返します。サーバーは熱的に安全でも、その変化する音調があらゆる小さな作業を聞こえるものにします。

ファンのヒステリシスが制御ループを断ち切る仕組み

ヒステリシスはコントローラーに記憶を与えます。温度が上限を超えてファンが加速した後、小さな温度の逆転ではすぐにその決定が取り消されません。温度が下限を下回るまで、コントローラーは遅い状態に戻りません。

例えば、ファンは50°Cで30%から45%に上がり、温度が46°Cを下回るまで45%のまま維持されることがあります。46°Cから50°Cの間は現在のファン状態が保持されます。この4°Cの差がヒステリシスバンド、またはデッドバンドです。これにより、センサーのノイズやその範囲内の小さな負荷変動が繰り返しRPM変化を引き起こすのを防ぎます。

これはACPI仕様で説明されている同じ制御原理です。プラットフォームはヒステリシスを実装する冷却しきい値を使用でき、アクティブ冷却装置はオンにした温度より低い温度でオフになります。正確なインターフェースは異なり、コントローラーによっては2つのしきい値を公開するものもあれば、温度差を公開するものもありますが、本質的な考え方は上昇と下降の判断が同じポイントで行われないことです。

ヒステリシス、応答時間、温度平均化は異なるものです

これら3つの制御はすべてファンの頻繁な変動を減らすことができるため一緒に扱われることが多いですが、制御ループの異なる部分で動作します。ヒステリシスはファンの決定を逆転させるために必要な温度条件を変えます。応答時間は新しい出力が受け入れられるまでの条件の持続時間を変えます。平均化はファンカーブに提示される温度信号を変えます。

修正方法を選ぶ際にはこの違いが重要です。温度が数分間同じステップ付近で推移する場合は、ヒステリシスバンドが直接的な解決策です。センサーがしきい値を1秒だけ超える場合は、短いステップアップ遅延や平均化されたセンサーの方が効果的かもしれません。実際の負荷変化中でもファンが2つの離れたRPM値の間で急激に変動する場合は、ステップレート制限やより緩やかなカーブが必要になることもあります。ファン制御のドキュメントではファンカーブのヒステリシスと応答時間を別々のパラメータとして扱い、時間平均化を別のセンサー機能として提供しています。

24時間稼働のサーバーでは、テストせずに3つの制御すべてで大きな値を積み重ねるのは避けてください。広いデッドバンド、長い平均化ウィンドウ、遅いステップアップ応答が組み合わさると、不必要に鈍い冷却システムになる可能性があります。より安全なパターンは非対称で、意味のある熱の増加には迅速に冷却を強化し、ファンの速度を下げるにはより明確な証拠を必要とします。

なぜ安定したRPMの方が音が気になりにくいのか

ヒステリシスは必ずしも最低または最高の音レベルを下げるわけではありません。その主な音響的利点は変化を減らすことです。35％のデューティで回るファンは、時折20％に達するファンよりも連続的な音を出すかもしれませんが、音の高さと気流が安定しているため無視しやすい場合があります。加速のたびにサーバーに注意が戻ってしまいます。

これが、平均RPMだけで静かさを判断できない理由です。Noctuaのファンカーブガイダンスでは、ファン速度の目立つ変化は一定速度よりも気を散らすことがあると説明しています。ヒステリシスは、冷却要求の意味のある変化を示さない反転を除去することで役立ちます。

限界はまだあります。70％のファンが一定速度で回っているからといって、それだけで静かになるわけではありません。サーバーが安定したRPMでうるさいままであれば、次に考えるべきはそのRPMが熱的に必要かどうかです。答えは、より良いエアフローパス、より大きく効率的なファン、制限の少ないグリル、低い持続電力、または企業用ハードウェアを使用中の部屋から離すことに関係するかもしれません。

ヒステリシスを設定できる場所

マザーボードが有用な制御機能を提供している場合は、BIOSまたはUEFIから始めましょう。ファームウェアベースの制御は、オペレーティングシステムが起動する前に動作し、アプリケーションがクラッシュしたりサーバーがメンテナンス環境で起動した場合でも有効です。ボードによっては、関連する設定が温度間隔、ヒステリシス、ファンスムージング、ステップアップ時間、ステップダウン時間、ランプ時間、または単にカスタムファンカーブと呼ばれることがあります。

用語はメーカーによって一貫していません。あるボードでは「ステップアップ時間」が変化の遅延を意味し、別のボードではデューティサイクルが新しい目標に向かう速度の制限を意味することがあります。BIOSでのファンカーブ設定ガイドは利用可能なカーブポイントやステップアップ/ステップダウン制御の種類を示していますが、サーバーのマザーボードマニュアルが正確な意味を示す権威です。

ファームウェアにヒステリシスがない場合や適切なセンサーを使用できない場合、ソフトウェア制御が有用です。WindowsツールはCPU、GPU、マザーボード、ドライブの入力を組み合わせることができ、Linux環境ではlm-sensorsのfancontrolやハードウェア固有のサービスを使用することがあります。専用コントローラーはドライブケージ、冷却液、吸気空気のプローブを追加できます。どの層を選ぶにしても、ファームウェア、OSサービス、GPUユーティリティ、BMCが同じファンヘッダーを奪い合わないようにしてください。各出力は一つのコントローラーが管理し、そのコントローラーが停止した場合のテスト済みのフォールバックを用意すべきです。

持続的な熱を隠さずにヒステリシスを調整する方法

まず、関係するファン、センサー、およびしきい値を特定します。サーバーが静かな状態、音が大きくなる時、そして落ち着いた後の温度とRPMを記録します。毎回同じ温度ポイントでRPMが変化する場合、ヒステリシスが関係している可能性があります。温度が数分間上昇し続けてRPMが上がる場合は、ファンは実際の熱に反応しているため抑制すべきではありません。

次に、信頼できる最小ファン出力を確立します。停止したファンは回転を開始するために、回転を維持するよりも多くのデューティが必要な場合があります。したがって、Linuxのfancontrolドキュメントでは最小ファン起動速度と停止速度を区別し、ファンの劣化に対応できる十分なマージンを持つ値を推奨しています。低ノイズ設定は、起動後やゼロRPM期間後にファンが時々起動しない場合は安全ではありません。

次に、最小限の有用なバッファを導入します。コントローラーの最小の非ゼロヒステリシス設定（通常は数度程度）から始め、振動を引き起こす曲線のポイントで設定します。曲線の上部の緊急領域は積極的に保ちます。インターフェースが別々のタイミングを許す場合は、本当に高温の境界付近では遅延をほとんどまたは全く使わず、システムが冷却された後の降温時にはより抑制的にします。

最後に、CPUだけでなくサーバー全体を検証します。最も暖かい想定室温で、CPU負荷、ストレージ活動、ネットワーク転送、メディアトランスコーディング、仮想マシン、またはアクセラレーターがあればそれを含む現実的な同時作業でテストしてください。CPU、マザーボード、VRM、メモリ、NVMe、ハードドライブ、およびHBAやNICがそれぞれの適用範囲内で安定することを確認します。熱アラーム、シャットダウン保護、全速フォールバックは有効のままでなければなりません。

ヒステリシスでノイズが修正できない場合

ヒステリシスは機械的または気流の問題を修正できません。一定の安定したRPMでのグラインディング音、カチカチ音、ガタガタ音、振動は、ベアリング、ケーブル接触、パネル共振、または取り付けの問題を示しています。常に高速で回るファンは、ほこり、詰まったフィルター、ヒートシンクの接触不良、排気の再循環、小型のクーラー、または実際に高い連続電力に反応している可能性があります。

低速のハム音や起動失敗も異なる問題です。ファンの起動電圧とスタール挙動に関する技術的ガイダンスでは、ファンを起動させるために必要な入力は回転を維持するための入力よりも高くなることがあり、低周波PWMは可聴の整流ノイズを引き起こす可能性があると説明しています。ヒステリシス帯域を変更してもどちらの状態も修復されません。最小デューティ比、制御モード、PWMの実装、またはファン自体を変更する必要があります。

ヒステリシスは、2つのコントローラーが競合している場合には誤った対処法です。BMCが周期的に全速を強制したり、GPUファームウェアがアプリケーションを上書きしたり、ファン制御サービスが別のプロファイルで再起動したりすると、RPMの変化は選択されたセンサーと全く関連しないことがあります。まずファンの所有権とフォールバック動作を解決し、一つのコントローラーがファンを予測可能に制御できるようになってからヒステリシスを適用してください。

よくある質問

ホームサーバーに適したファンのヒステリシス値は何ですか？

普遍的な値はありません。コントローラーがサポートする最小の非ゼロ帯域（通常は数度）から始め、騒音を引き起こすしきい値で設定してください。RPMがまだ振動する場合にのみ増やし、温度が意味のある動きをしているのにファンが不適切な速度のままなら減らします。正しい結果は、短時間のバースト中は安定した音響で、持続負荷時には迅速な冷却です。

アップ遅延とダウン遅延は同じにすべきですか？

通常はそうではありません。ホームサーバーは持続的な温度上昇に比較的迅速に反応し、冷却後はよりゆっくりと落ち着いて戻ることが望ましいです。ただし、一部のファームウェアはランプレート制限を遅延とラベル付けしているため、非対称値を選ぶ前に特定のマザーボードやコントローラーで設定が何をするかを確認してください。

ファンのヒステリシスは24時間稼働のサーバーに安全ですか？

はい、控えめでテスト済み、かつ熱保護に従属している場合に限ります。安全な運用には、信頼できる最小ファンスピード、応答性の高い高温領域、持続負荷の検証、温度アラート、そして制御や冷却が失敗した場合にファンスピードを上げるかサーバーをシャットダウンするフォールバックが必要です。

最終的なまとめ

ファンのヒステリシスは、温度しきい値付近での迷いがちな速度変化を防ぐことで、常時稼働するホームサーバーの騒音を抑えます。熱を無視するのではなく、前回の冷却判断を取り消すにはより意味のある温度の反転が必要です。これにより、気になる急激な変動がより安定した音響背景に変わります。

しきい値のチャタリングにはヒステリシスを使用し、短時間の状態には応答時間を、ノイズの多いセンサー入力には平均化を用います。安全なファンカーブと信頼できる最小デューティから始め、一度に一つずつ小さな変更を加え、現実的な持続負荷下で結果を検証してください。RPMが安定してもサーバーがうるさいままなら、デッドバンドを広げるのをやめ、ファン、気流、熱源、または競合するコントローラーを調査してください。