CosmosBlueのブログ

日々のよもやま話を徒然と

YouTubeの音切れが直らない(NUC13ANHi3 Windows11 23H2 Bluetooth)

続けてBluetoothネタとなりますが、自宅PCをNUC13 ANHi3にリプレース後、Windows11 23H2になった頃からYoutubeの視聴で微妙にストレスを感じるようになりました。音切れ・音飛びです。症状は二つ。一つは1秒未満ではあるが明らかに認知可能な一瞬の音飛び、もう一つは再生中に2~5秒程度の音切れ(冒頭ではなく再生途中での無音)です。この際に映像は止まりません。

4時間の視聴だとすると、音飛びは5~6回、音切れは多くて2回(1回は必ず)というレベルで、視聴に耐えないとまではいきませんが地味にストレスが溜まります。

Bluetoothバイス

そもそも症状が発生しているのがBluetoothネックスピーカーなので、原因が多すぎて切り分けも難しいです。NUC13ANHi3でざっと上げれば以下の可能性があります。

Webで検索すると、まずプロバイダのネットワーク遅延を疑うことから始まりますが、Youtubeプレイヤーがクルクルになって映像も音声も止まっているならいざしらず、映像は動いているという点で積み荷が間に合わないという線はありません。なのでネットワーク遅延は無視(v6プラスですし)。

また、原因を切り分ける前に、Bluetoothだけかどうかを大枠で判定するために、ディスプレイがHDMI接続なら、ディスプレイのイヤホンジャックにイヤホンをつないでYoutubeを視聴してみてください。自分の場合、HDMI経由のイヤホンではYoutubeの音切れ・音飛びはありませんでした。

では、Bluetoothだけおかしいという前提で切り分けていきます。


Youtubeコンテンツ

音切れ・音飛びを感知したらプレイヤーのスライダーを戻して確認していますが、編集の継ぎ目などでコンテンツが元からそうなっているケースもあり、これは不具合としては除外します。音切れも音飛びも、巻き戻して再生すると正常なケースのみ不具合としています。


Youtubeプレイヤー

ブラウザで動作するYoutubeプレイヤーのバグだとするとGoogleが直してくれるまで待つ必要があります。不特定のアカウントをサンプリングして新機能を密かにテストすることもありますが、匿名アカウント(Googleアカウントをログアウト)でも発生するので可能性は薄いと感じました。


Chrome

バージョンは最新。同じChromiumエンジンのEdge、ChromiumではないFirefoxでも症状は出るのでブラウザではないと判断します。


Intel UHD Graphics (GPU)

Chromeで「ハードウェアアクセラレーションが使用可能な場合は使用する」にチェックを入れていますが、そもそも映像は止まっていないのでGPUのVideo decodeに不具合があるとは考えられません。このチェックを外すと音飛びが直るという方もいますが、負荷の高い処理をわざわざGPUからCPUに持ってきてCPU負荷を上げることになるので、この解決方法は自分にとって最善ではありません。


Intel SST (Digital Audio processor)

デジタルオーディオの統合プロセッサーです。切り分け方としては、iTunesなどの音源ファイルをコンピュータにお持ちの場合は(無ければ音楽CD/DVDなど)それを再生して1時間ほどイヤホンなどで聴いてみてください。問題がなければこのプロセッサーに不具合は無いと思います。


Intel AX2xx (WiFi/Bluetooth processor)

NUC13ANHi3ではAX211で無線通信を司るプロセッサーです。WiFiBluetoothが使えているのなら不具合は無いと思います。同じ2.4GHz帯だと双方が干渉することはあり得ますが、自分の場合は有線LANを使っていて通常時WiFiは無効にしていますので、これは原因ではないと判断します。


Intel ワイヤレスBluetooth Driver

最も怪しいのはこいつですが、NUC13 ANHi3を仕立てて以降に3世代バージョンアップしており、最新を保っていますが症状は無くなりません。また、ローカルの音源ファイル再生では音切れ・音飛びは無く、ストリーミングだけで発生するので基底のBluetoothドライバが原因というのは(疑いたくても)無理がありそうです。


サウンドバイスのドライバー

Bluetoothサウンドバイスのうち、症状が発生するのはネックスピーカー二種(SHARP AN-SS2とSONY SRS-NB10)で、TWSイヤホンでは発生を確認できません。ただ、お世辞にもYoutubeの音質は高くないのでカナル型イヤホンで長時間視聴するのがキツく、TWSではきちんと検証出来ていないのが実情です。TWSでは「発生しません」とは言い切れません。

これらのデバイスはメーカーからの個別ドライバー提供は無く、揃ってMicrosoftの標準ドライバーがインストールされています。Alternative A2DP Driverという有料ドライバー(の試供版)に入れ替えても症状は発生しましたので、個別ドライバーは原因ではないと思います。


サンプリングレート

音声データの送り側と受け側のサンプリングレートが異なる場合、音切れ・音飛びが出やすいと聞きます。しかし、ローカル音源ファイルを再生した際、iTunes Music Playerは16bit / 44.1kHz、ネックスピーカー側は16bit / 48kHz、これで問題ありませんでした。ネックスピーカー側は48kHzしか対応できないので前述Alternative A2DP Driverで送り側を48kHzにしてみましたが症状は無くなりませんでした。


コーデック

SHARP AN-SS2はaptX、SONY SRS-NB10はAACで接続していますが、どちらにも発生するのでコーデックではないと思います。どちらもSBC接続にできますが、SBCでも同様でした。前述Alternative A2DP Driverでも確認できました。


無線障害物

障害物は特になく、視聴中のPCとネックスピーカー距離は50cm~80cmほどです。無線の妨害波は目に見えないので対処のしようがありませんが、スマホアプリのBluetooth強度測定では特に乱高下する様も見られず、電波は「強」のままでした。


サウンドバイス

ネックスピーカー(のDAC)そのものが故障している可能性ですが、異なるメーカーの異なるデバイスが同時に同じ壊れ方をするとは考えにくいため、これは却下かな。


 

という訳で切り分けた結果、被疑箇所が無くなってしまいました・・・

自分としてはもうYoutubeプレイヤーのせいだと思い始め、Googleが直すのを待つしかねえかな、と半ば諦めかけていました。しかし、そこで思考はNUC13を仕立てた当初へ。

そもそも音が飛んでるなと気付いたのはいつ頃だっただろう?NUC13 ANHi3を仕立てたばかりの頃はどうだったろうか?と記憶を探り始めます。もちろん明確な記憶はありません。そこで環境を戻してみるという発想に至ります。と言ってもWindows11のクリーン再インストールは絶対にイヤですし、仕立てた当時のWindows11 22H2状態に戻すのは難しい。

では、ここまでアップデートしたドライバー類をバックワードしてみよう、と思い立ちました。やみくもに色んなドライバーを古いバージョンに戻すのもメチャクチャになりそうなので、まずはインテルワイヤレスBluetoothドライバのバージョンを下げていくことにしました。

今は「インテルワイヤレスBluetooth 23.10.0.2」が入っており、2024年2月11日現在でダウンロードできる過去バージョンは「22.250.0.2」と「22.240.0.2」だけです。そして、どちらも過去に手動アップデートしてきたバージョンです。ところがこの手動アップデートでは基本的に古いバージョンのドライバーにアップデートをすることができません。

で、仕方なく一回「デバイスのアンインストール」を行うと「インテルワイヤレスBluetooth 22.190.0.2」というドライバが自動的に適用されて復元しました。2022年11月のドライバーです。

インテルワイヤレスBluetooth 22.190.0.2

Windows Updateの履歴を見るとNUC13 ANHi3を仕立てた日、おそらくインストール終了後のWindows Updateで入ってきたドライバーだと思います。

Windows Update履歴

意図せずNUC13 ANHi3を仕立てた時のドライバーを入手したので、この「インテルワイヤレスBluetooth 22.190.0.2」でYoutubeを視聴すると、なんと、音切れ・音飛びが無くなりました。信じられません。そうです、結局一度は嫌疑不十分で釈放した基底のBluetoothドライバーが犯人でした

Intelの汎用Bluetoothドライバが更新される都度、手動でアップデートしていたことがいけなかったと見るべきでしょうか。もしくは常に最新が良いとは限らないというアンチテーゼでしょうか。まあ、とにかくYoutubeの音声不具合は沈静化したのでこれで良しとします。しばらくは手動アップデートを控えることにします。でもなぁ、ストリーミングだけ発症していた理由は未だに分からないんすよね。

今回は「おま環」色が強くてすいません。万人に適用可能な解決策とは言えませんでしたが、何かっていうと口を揃えて「ドライバーを最新にアップデートしてください」と言うけど、必ずしもそれが正しいとは限らない、そんな出来事でした。

 

2024年3月26日 追記:

23.30.0.3が出ていたのでインストールしてみました。ダメなら削除すればまた22.190.0.2になるので気軽に試してみています。が、意外にも音切れは出ないですね。Fixed Issuesにはスリープ復帰時の安定性とゲーム関係しか書かれておりませんけど。

「ほかのデバイス-Bluetooth周辺デバイス」を消す(Windows11 23H2)

バイスマネージャで目に付く「?」マークの付いた「ほかのデバイス」。自分の場合「Bluetooth 周辺デバイス」が3つありました。Windows11 23H2でこの状態なのですが、正確にはいつから存在していたのか記憶がありません。「!」マークと違って「?」マークは必ずしもエラーを示している訳でもないようです。

ほかのデバイス

この「Bluetooth 周辺デバイス」は、削除しても再起動すれば復活するし、何のドライバを当てれば良いのかWindows自身も分かっていないから「?」なので、オーナーにはどうしようもありません。多くの方は放置しているのが現状と思います。結論から言うと放置で構わないと思いますが、今回この「Bluetooth 周辺デバイス」が何故出来るのか分かりましたので消してみました。

自分の場合はすべて「Bluetooth 周辺デバイス」ですので、Bluetoothバイスを確認します。まずは「設定」-「Bluetoothとデバイス」-「デバイス」と進み、「その他のデバイスとプリンターの設定」を押します。

その他のデバイスとプリンターの設定

すると懐かしいコントロールパネルの「デバイスとプリンター」画面が現れます。

バイスとプリンター

いずれかのBluetoothバイスを右クリックしてプロパティを選択します。

バイスを右クリック

そして表示されたデバイスのプロパティで「サービス」タブを選択してください。ここで「不明なサービス」にチェックが入っている場合、「ほかのデバイス」に表示されている可能性があります。

不明なサービス

「可能性があります」と言うのは、この「不明なサービス」が必ずしも「ほかのデバイス」に表示されているとは限らず、正規ドライバーの可能性もあります。

例えば、「不明なサービス」のチェックを外す前のデバイスマネージャの状態は以下です。

バイスマネージャ(実験前)

ここで「不明なサービス」の下一つをチェック外して「適用」を押してみます。

不明なサービスのひとつを消す

ところが無くなったのは「ほかのデバイス」ではなく、「JVC HA-A11T L A2DP SNK」というサウンドドライバ類でした。

ハズレ「不明なサービス」

バイスのプロパティを元に戻し、次にもう一方の「不明なサービス」をチェック外して「適用」を押してみます。

もう一方の「不明なサービス」を消す

すると、「ほかのデバイス」「Bluetooth 周辺デバイス」がひとつ消えました。

ほかのデバイスがひとつ消える

このように、すべてのBluetoothバイスのプロパティでサービスタブを確認し、デバイスマネージャとにらめっこしながら「不明なサービス」のチェックを外していくと、最終的には「Bluetooth 周辺デバイス」?は無くなりました。自分の場合はTWSイヤホンの左右で各1個、ネックスピーカーに1個ありました。

で、消してみて何か変わったかというと、特に何も変わっていません。そもそもこの「不明なサービス」が以前は何だったのか分かっていません。もしかしたらスマホやTVには必要でもWindows11には必要のないものかもしれません。

これらの「ほかのデバイス」「Bluetooth 周辺デバイス」?にはNULL Driverという毒にも薬にもならないドライバーがインストールされています。つまり使わないけどエラーでもないのでとりあえず存在しないドライバーを当てておこうというものです。したがってこれがあっても何らリソースは消費していません。

これらを考慮すると、特に消す必要もなく、放置しておくのが一番良いのかなと思います。ちなみにペアリング解除して再ペアリングすると「ほかのデバイス」としてフツーに復活します。それでも「私はこういうのがあると許せないたちだ」という方は、少なくとも「Bluetooth 周辺デバイス」に関してはこれで消せると思います。

 

完・NUC13 ANHi3 Cooling設定に悩む

さて、第三部に突入してしまったNUC13 ANHi3のクーリング設定ですが、前々回は「静音低温なるべく性能キープ」の探求、前回は「ハイパフォーマンスなるべく静音低温」の探求をしてみました。今回は高負荷続きでもギリギリ青信号(70℃台)に留まる「バランス静音低温」設定を探求してみます。

クーリング設定に関しては、前回までにある意味答えが見えてきていて、日常作業域が収まるCPU温度までは気にならない最高回転数をMinimum Duty Cycleに与えるということになります。前回記事ではMinimum Duty Cycle: 39%を64℃まで引っ張るようにしました。自分は回転数の急増減による変調音が嫌いなため、Ramp Down Rateを25%にして緩やかな減衰にしました。静音低温は日常作業域を基本にしますので、クーリングはここまでの設定を踏襲とします。

次に電力設定についてですが、これも前回までにある程度見えていて、80℃を超えたくないなら最初のバーストモード時間を縮める、あるいはワットを抑える、またはその両方でピーク温度を下げることは可能です。ただ、前回CINEBENCHを用いたテスト挙動において、温度、クロック、ファン回転数などのバタつきが気になっているので、まだ何か出来ることを考えます。

前回の設定は以下でした。

PL1: 20W, PL2: 28W, Tau: 28秒

今回はPL2を推奨値の1.3倍より低い1.25倍、Tau前回推定から8秒以上22秒以下の16秒としました。

PL1: 20W, PL2: 25W, Tau: 16秒

PL1: 20W, PL2: 25W, Tau: 16秒

更に「Power」を「Max Performance Enabled」に変更します。

Max Performance Enabled

ここは全く説明が表示されないので自分も理解が薄いのですが、音切れや映像がカクつく場合にここを「Max Performance Enabled」にしたらいいよ的な記事を過去に見た記憶があり、CPU省電力の度合いをプリセットしたものではないかと推測します。

だとすれば「Max Performance Enabled」でなるべく省電力ステートに移行しないようにできたりしませんかね。というのも、Windows OSがやっている遅くて下手な省電力スイッチングを極力ハードウェアに譲ることで、負荷時のバタつきが改善されないだろうかというのが変更動機です。

次はWindowsOS側のCPU電源管理を変更していきます。無用なソフトウェア制御を取り払っていこうと思います。この後の記述は Windows11 23H2基準になります。Windows10や10からアップグレードした11の場合は異なっている可能性があります。

まず、電源オプション「プロセッサの電源管理」で隠れている各項目を表示させるためにレジストリを変更します。レジストリエディタで以下のレジストリキーへ移動します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\54533251-82be-4824-96c1-47b60b740d00

さらにその配下のサブキーにある「Attributes」の値を1から2へ変更します。自分がプロセッサ電源管理で表示させたのは以下のサブキーです(結果として変更しなかったものを含む)。

  • 0cc5b647-c1df-4637-891a-dec35c318583
  • 3b04d4fd-1cc7-4f23-ab1c-d1337819c4bb
  • 447235c7-6a8d-4cc0-8e24-9eaf70b96e2b
  • 5d76a2ca-e8c0-402f-a133-2158492d58ad
  • 893dee8e-2bef-41e0-89c6-b55d0929964c
  • bc5038f7-23e0-4960-96da-33abaf5935ec
  • be337238-0d82-4146-a960-4f3749d470c7
  • ea062031-0e34-4ff1-9b6d-eb1059334028

電源オプション「プロセッサの電源管理」

設定値とその概要は以下のとおりです。

プロセッサの電源管理 設定値(1/2)

プロセッサ パフォーマンス コア保留の最小コア数

コア保留というのはタスクマネージャのCPUパフォーマンスで「なんだコレ」といつも思っているこの状態のことです。

コア保留されたCPUスレッド

コア保留とは、使用するコアを集中し、他のコアのスケジューリング優先度を落とすことによって省電力化を図ろうとするものです。保留されているコアでも必要な場合はすぐに活動を始めますが、このスイッチングをOSソフトウェアが行なうことで遅延し、先頭で活動中のP-Core #0が電力を食べて高熱化する、という仮説を解消する試みです。

「パッケージのコア数÷コア保留解除を許容するコア数」なので100%を設定するとコア保留が無効になります。


スロットルの状態を使用する

これはかなり意味不明なんですが、PステートとCステートの管理をOSではなくCPUに丸投げします、と理解しました。遅いソフトウェア制御よりも近代CPUによる制御の方が速いため、そちらで制御を行いますという場合は「オン」にします。「オン」にするとBIOSで設定した「Max Performance Enabled」が適用されると(勝手に)思ってます。微々たる性能向上目的ではなく、これもソフトウェアによるスイッチング遅延を解消したい目的です。


プロセッサ パフォーマンス コア保留の保留時のパフォーマンス状態

コア保留を無効にしたので変更なし(デフォルトのまま)


プロセッサ アイドル無効

アイドルしても良いので変更なし(デフォルトのまま)


 

プロセッサの電源管理 設定値(2/2)

最小のプロセッサの状態

デフォルトのまま(5%)


最大のプロセッサの状態

前々回ここを99%にしてE-Coreが1.2GHz固定になったのでデフォルト(100%)に設定


プロセッサ パフォーマンスの向上モード

デフォルトは「アグレッシブ」ですが、アグレッシブはコアのピーク温度が高かったので、それぞれを簡単に試してみた結果、最もバランスが良かった(と思えた)「効率的なアグレッシブ」にしました。


プロセッサ パフォーマンス コア保留の最大コア数

コア保留が解除されているコアの許容最大数です。最小コア数と共に100%の場合はコア保留が無効になりますのでデフォルト(100%)のまま。


 

では、この設定でCINEBENCH 2024を実行します。

はい、実行しました、結果です。

CINEBENCH 2024 20-25-16 Result

前回のスコアは298ptsでしたので今回は1pts減りました。これは誤差の範囲と言って良いかは分かりませんが、ほぼ同等と考えておきます。次にコア温度と電力の推移を見てみます。

CINEBENCH 2024 20-25-16 Core Temperature & Watts

P-Core#0とP-Core#1の平均温度は前回から1℃弱下がり、瞬間最高温度は77℃と目標は達成できました。

次にCINEBENCH開始から30秒のバースト電力推移を見てみます。

CINEBENCH 2024 開始から30秒までのパッケージ電力

ここでおかしなことに気が付きます。Tau: 16秒なのに23秒間もバーストモードが続いているように見えます。「なんだこれ」と思いつつもHWiNFOのログを眺めていると、ある項目に気が付きました。「 コア消費電力制限を超えました (avg) 」という項目です。この項目はPL1電力制限をされているか否か、測定間隔毎にYes/Noで出力します。これで分かりました。

CINEBENCH 2024 開始から30秒までの電力制限と解除

CINEBENCHの測定ボタンを押した後、7秒と11秒にPL1電力制限が解除された記録がありました。PL1電力制限が解除されれば、再度PL2バーストモードを使う権利が発生します。開始30秒の間に3回のバーストモードがあり、3回目は16秒バーストした後ベンチマーク終了までPL1電力制限が続いていました。「なるほど~」と思いました。

そして、CPUファンの回転数推移です。

CINEBENCH 2024 20-25-16 CPU Fan RPM Transition

ある意味このグラフが一番衝撃的でした。「こうだよな、こうあるべきだよな、だが何故だ?」という謎の衝撃です。基板CPUセンサー温度と並べたものがこちらです。

CPU温度とファン回転数(今回)

ちなみに前回ガッタガタだったCPUファン推移はこちらです。

CPU温度とファン回転数(前回)

ガッタガタと言いつつも、実は前回テスト結果の方が設定に忠実なCPU回転数推移なのです。しかし同じクーリング設定で今回のは美しすぎますよね。では、おかしいのは今回の方でしょうか。

前回は76℃と73℃の間で見た目派手にファンが動いていますが、今回は2,800rpmに留まりあまり上下動していません。まるで「負荷が続いているからいちいち下げるのやめといたわ」と言っているようです。自分が見たものに意味を与えたいだけなのですが、これって「Max Performance Enabled」の効力と思いたくなります。

最後に今回のパラメーターをまとめます。

  • BIOS "Power"
    • Max Performance Enabled: checked
  • BIOS "Cooling"
    • Package Power Limit 1:20W
    • Package Power Limit 2:25W
    • Package Power Time Window:16s
    • Fan off Capability:Disabled
    • Primary Temperature Sensor:CPU
    • Secondary Temperature Sensor:CPU Voltage Regulator
    • Maximum Temperature:90
    • Minimum Temperature:64
    • Fan Cut-off Temperature Offset:20 (ignore)
    • Minimum Duty Cycle:39
    • Duty Cycle Increment:2
    • Sample Period:1
    • Ramp Down Rate:25%
  • OS "Power Management"
    • プロセッサ パフォーマンス コア保留の最小コア数: 100%
    • スロットルの状態を使用する: オン
    • プロセッサ パフォーマンスの向上モード: 効率的なアグレッシブ

夏になったらまたいじる可能性がゼロではありませんが、一旦はこれで満足できる結果が得られましたので、これでNUC13 ANHi3のクーリング設定については完了とします。

i3-1315Uはオンボード専用でリテールがありません。つまりこのCPUに出会うにはそれが実装された商品としてのPCを買うしかありません。NUCはその一つですが大抵はノートPCです。PL2を含めベンダー調整値でロックされているものも多く、BIOSもあまり自由に設定できませんし、クーリングシステムの変更もできません。それでも何か出来ることはあるだろうと始めたことで、そこそこの結果を得られたので良かったと思います。

ただ、BIOS/UEFIの知識が無く、このNUC13ANHi3をオシャレなミニPCとして購入した人は、うるさいわ、熱いわで結構大変でしょうね・・

 

 

※この記事はBIOSレジストリの操作を推奨するものではありません。古くからBIOSレジストリの編集・変更にはリスクが伴うことは知られています。また、クーリング設定をプリセットから変更した時点でクーリングの責任はユーザーに移ります。それが原因でNUCが故障した場合はIntelのWarrantyが効かなくなる場合があることをご承知ください。

ご自身のPCをご自身の責任でいじられることは何の問題もありませんが、結果については常に自己責任であることを認識して頂ければと思います。この記事によって被ったあらゆる損害についてブログ主は免責とさせて頂きます。

続・NUC13 ANHi3 Cooling設定に悩む

前回NUC13 ANHi3で快適静音クーリング設定を目指して、一通りの解を得たのですが、もう少しハイパフォーマンスにしても大丈夫かなと思い、設定を大幅に変更してみました。前回記事への追記が多く見づらくなってきたので、ハイパフォーマンス設定部分をこちらに切り出します。

で、前回追記で既存保有機であるNUC11 PAHi3のクーリング設定(プリセット「Balance」)を確認してみたのがこちらです。NUC13 ANHi3とはTDPが異なるためPL1, PL2がかなり大きいですが、Minimum Duty Cycle35%を64℃まで引っ張っているのが分かりました。

  • ※ NUC11 PAHi3 Setting (Preset "Balance")
  • Package Power Limit 1:30W
  • Package Power Limit 2:64W
  • Package Power Time Window:28s
  • Fan off Capability:Enable
  • Primary Temperature Sensor:CPU
  • Minimum Temperature:64
  • Fan Cut-off Temperature:30
  • Minimum Duty Cycle:35
  • Duty Cycle Increment:2

NUC11 PAHi3のアイドル時ファンは1,880~1,920rpmあたりを行ったり来たりしていました。同じrpmが同じ風量とは言い切れないのですが、NUC13 ANHi3で1,900~1,950rmpは39%にあたります。これを参考に、以下のような、もう少しハイパフォーマンスを求めた値に設定変更してみます。

  • ※ NUC13 ANHi3 Setting ( Custom )
  • Package Power Limit 1:20
  • Package Power Limit 2:28
  • Package Power Time Window:28
  • Fan off Capability:Disable
  • Primary Temperature Sensor:CPU
  • Secondary Temperature Sensor:CPU Voltage Regulator
  • Maximum Temperature:90
  • Minimum Temperature:64
  • Fan Cut-off Temperature Offset:20 (ignore)
  • Minimum Duty Cycle:39
  • Duty Cycle Increment:2
  • Sample Period:1
  • Ramp Down Rate:25%

上記の設定で、とある一日の温度をモニタリングしてみました。何かテストをしたという訳ではなく、2024年1月15日の9:00から23:00まで日常用途で使ったものですので、意味があるのはMax値だけです。

ハイパフォーマンス設定のHWMonitor記録

ファンを左右するCPU Temperatureは73℃で若干高め程度でも、コアのデジタルサーマルセンサーは82℃まで行っています。ほぼ一瞬だとは思いますが、どれくらいの時間で何回くらいあったのかは気になるところです。音は全く気にならなかったです。

さて、今までベンチマークはいたずらにCPUを痛めそうなので敬遠してきましたが、今回はCinebench 2024をかけてみることにしました。継続的な負荷でいったいどの程度の高温域に滞留するのかを知るためです。

まず室温21℃でCinebench 2024のMulti Coreを走行させた結果です。

NUC13ANHi3 Cinebench 2024 Mulit-Core Result

皆さん土俵を合わせるためにCinebench R23を使うケースが多いので、Cinebench 2024の"298pts"がいかほどの成績かはよく分かりません。ちなみにNUC11PAHi3は"163pts"でした(BIOSデフォルト、Coolingはプリセット「Balance」の値)。

ここでは性能評価は置いておき(とは言っても11世代より高性能で良かったです)、温度の結果を見ましょう。こちらです。

Cinebench 2024 HWMonitor Result

このキャプチャで意味があるのはMax値だけです。ベンチ中の概要をお伝えしますと、Coreのデジタルサーマルセンサー値はほぼ74℃~77℃の範囲で瞬間最大が88℃、基板のCPUセンサー値は75℃が大半の時間を占めて瞬間最大は85℃、ファン回転数は2,930rpmでの動作が最も時間を占めて瞬間最大は3,291rpmでした。

Core Tempの結果もほぼ同様です。

Cinebench 2024 Core Temp Result

Tj. Max(サーマルスロットリングが動作する温度)が100℃ですが、瞬間最大温度はまったくそこまでは達していません。IA CoreとPackageのWattsをずっと見ていましたが、20Wでの動作をなんとか達成しようとしてWattsオーバーをカットしている様がよく見て取れました。瞬間最大値は最初にTurbo Boostが28秒効くところで記録しているように思います。つまりCPUへの供給電力がある時点(Package Power Time Windowが終わる時点)で頭打ちになるため、その後はクロックが上がりきらず、本来の性能(Max Turbo状態)より低下した状態で推移している、すなわちそこで高温化が止まるのだと思われます。

こう見ると、日常使いでは50℃台平均(瞬間最高が70℃台)、高負荷が10分続く環境でも70℃台平均(瞬間最高が80℃台)となり、このクーリング設定でも日常的にCPUを痛めつけることは無いように思います。瞬間最大が80℃台後半はイヤだという場合はPackage Power Time Windowにまだ検討の余地があります。

ただ、2,500rpmを超えるともはや静音のレベルではありません、うるさいです。ベンチマーク中の最頻値2,930rpmはそりゃもう轟音でした。結局手を緩めるとすぐに温度上昇するので82℃くらいの回転数から降下できないのですね、おそらくは。これはRamp Down Rateを低くしているための効果かと思います。逆に音で高温になっているのに気付くというメリットはありますが。

しかし問題は、自分の利用環境でそこまでの負荷状態に通常なるか?ということであって、うるさいファンに耐えるという課題を抱えている訳ではありません。いざ、のっぴきならない状況になってしまった場合でも黄色信号で済む、という安心感の上で利用できるパフォーマンスというのは魅力でもあります。

さて、ここまで「低温静音なるべく高性能」設定と「ハイパフォーマンスなるべく低温静音設定」をやってみました。みなさんはどちら派でしょうか。

 


 

# なぜか終始 P-Core#1君はクールなんですよね、というかCPU使用率は#0とほぼ同じですし、HWiNFOで見ても平均温度はそんなに差は無いんですよね。なのでクーリングの偏りというのは無いと思うんですね。しかし、Max値に記録される最大瞬間温度はいつもP-Core #1の方が10℃くらいP-Core #0より低いんですよ。ダイのレイアウト(本物か分からないけど)を探して見てみたのですが、P-Core、E-Core共に配置はシンメトリーで、隣り合うチップは#0も#1も同じに見えました(どちらかがPCIに近いとかGPUに近いとかではなく)。NUC11では2コアがほぼ同じMax温度でした。

「まあ、気にすんな」というのが大方の意見だと思いますが(気になる~)。

2024/3/2追記:

P-Core#0とP-Core#1の温度差はどうやら「熱しやすい13世代 + Hyper Threadingの特性」に起因するみたいです。ざっくり言うと、P-Core#0のスレッドである論理のCPU0とCPU1が埋まり、CPU2とCPU3のどちらかに余裕がある状態が維持されると、温度はP-Core#0の方が高くなる(バーストモード区間なら尚更)という理屈です。

で決定的な原因、実はHWMonitorやHWiNFOのようなモニタリングソフト自身でした。これらはCPU0に乗り、秒間隔でモニタリング負荷をかけています。つまりP-Core#0はP-Core#1より余計な負荷が常時かかっています。

そこで、タスクマネージャの「関係の設定」でこれらモニタリングソフトはE-Core(CPU4~CPU7)しか使えないようにすると、P-Core#0とP-Core#1は平均値もMax値もほぼ同温で推移するようになります(Hyper Threading切らなくて大丈夫です)。

温度を見るためのソフトで温度の偏りが生まれていたんですね。DTSのキャリブレーションがおかしいとか、そういう訳ではなかったようで良かったです。

 

という訳で、要約や推測ではなくHWiNFO64で出力したログからグラフを起こしてみました。まずCPU温度と電力の関係です。E-CoreはP-Core#0とP-Core#1の間に収まっていて、そのせいでグラフが非常に見にくくなるのでE-Coreのグラフはカットしています(とは言えE-Coreも気になる方には4コア揃って安定の71℃平均とお伝えしておきます)。

CINEBENCH 2024中のP-Core温度とPackage電力の推移

P-Core#0とP-Core#1の温度に常に5~6℃程度の差があることを除いては、CPU Packageとしてはものすごく律儀にPL1とPL2が守られているのが見て取れます。

ベンチマーク開始からキッチリ28秒間はPL1時間(Package Power Time Window)が有効になり、PL2の28Wで電力はカットされています。その後はPL1の20Wを堅守しようと頑張っています。ハッキリ見えてスゴイですこれ。

また、この間のCPUファンの回転数推移は以下になります。

CINEBENCH 2024中のCPUファン回転数推移

ピークはCPUがTurbo Boostで83℃を記録した序盤の3,291RPMで、その後は平均で2,892RPMとなっています。2,892からMinimum Duty Cycleの1,950を引くと942なので、1%みなし50rpmで計算すると+19%となります。64℃から温度毎に2%増加なので約9.5℃上昇、つまりCPUファンの数値から見た場合、73.5℃がベンチマーク中の平均CPU温度となっているはずです。実際にCore温度のログで計算するとP-Core#0総平均が73℃、P-Core#1総平均が68℃となっていました。辻褄が合って良かったです。

次にPackage Power Time Windowで設定するPL1時間(バーストモード)について見てみます。開始から33秒までの部分拡大グラフが以下です。

CINEBENCH 2024 開始から33秒までの温度と電力


このグラフの線形を見るに、供給WattsをP-Core#0とP-Core#1で配分する中で、ややP-Core#0が多めにガメている(P-Core#0に多くのオーダーが行っている?)ように見えますね。

また、このグラフからは、もしバーストモードでも70℃を超えたくないのであれば、PL2を23W以下、Package Power Time Windowを8秒以下にすべし、ということが分かります。さらに、80℃を超えたくないのであれば、PL2を28W以下(今回設定ですね)、Package Power Time Windowを22秒以下にすべし、ということも分かりました。

いずれも毎回同じように推移する訳ではなく、高いベース温度から始まればターゲットを簡単に超えてしまうでしょう。そのためのバッファを考慮するともう少し低い値にする必要があるかもしれませんね。

連続する一つのセッションで瞬発力を出すなら8秒でも良い気がしますね。CINEBENCHのように20分近く高負荷を続けるものに対して最初の28秒だけダッシュしてもほとんど効果ないですし、やはりバーストモードは重たいアプリの起動等をサポートする時間分あれば良い気もしてきます。

次回「完・NUC13 ANHi3 Cooling設定に悩む」でこのクーリング課題を完結します。

 

 

※この記事はBIOSの操作を推奨するものではありません。古くからBIOSの編集・変更にはリスクが伴うことは知られています。また、クーリング設定をプリセットから変更した時点でクーリングの責任はユーザーに移ります。それが原因でNUCが故障した場合はIntelのWarrantyが効かなくなる場合があることをご承知ください。

ご自身のPCをご自身の責任でいじられることは何の問題もありませんが、結果については常に自己責任であることを認識して頂ければと思います。この記事によって被ったあらゆる損害についてブログ主は免責とさせて頂きます。