Dell の Vostro 3500 を購入しました。
なんだかんだで使い勝手がよく、G401IHは完全に自宅での開発パソコンになり、Vostro 3500 がZoom サポート用なだけでなく、出張に持ち運ぶパソコンとなりました。
メインパソコンって、用途別に両方ともメインパソコンって感じです。
で、休止を使うようになって、移動中の電力消費の問題は解決したんですが、やっぱり、ちょっとした会議室移動などは、スリープで乗り切りたい。電車移動中も休止でなくスリープでいけないかなって。
消費電力削減の結果
ということで、sleep中の電力消費を減らせるか試したところ、800mW ぐらいまで減らすことができました。これだと、当然、全く発熱してないですし、40Wh ぐらいのバッテリだったら、満充電で 40時間はスリープさせられる計算になります。
結論としては特定アプリを閉じてからスリープするとスリープ中の消費電力が削減可能
結論としては、スリープ中にデバイスを起動しっぱなしにするアプリは落としてからスリープするっていう事になりました。
せっかくのスリープなので、何を立ち上げていても良さそうなんですが、コネクテッドスタンバイの場合、スリープ中も動くってことで仕方ないんですね。
で、原因となるアプリは人によってケースバイケースだと思いますが、僕の場合、スリープ中97%以上、「インテル スマート・サウンド・テクノロジー・オーディオ・コントローラー」が電力消費をしてました。
といっても直接デバイスドライバーが悪いわけではなく、動画キャプチャソフトのBandicam が悪さしてました。原因かどうか自信なかったのですが、Bandicamを閉じてから確認したら、スリープ時の消費電力がぐっと減りました。
その前にコルタナもスタートアップから削除してたので、原因の特定ははっきりできていないです。コルタナは原因ではなかった可能性もあります。まあコルタナを使ってないのでOFFのままにしていますので、コルタナが原因かどうかを確認するテストは行わないつもりです。
計測の方法
コネクテッドスタンバイ中の電力消費を計測というか、計測は自動でされてるので、計測結果を表示するために、powercfg コマンドを使用します。
コマンドプロンプトか、パワーシェルからコマンドを実行するのですが、面倒なのと、管理者権限で実行しなくてはいけなくて、面倒です。
なので、テキストエディタでバッチファイルを作って、管理者権限で実行したほうが良いです。
計測バッチファイル
以下のファイルになります。bat_sleep_report.bat などという拡張子batのバッチファイルを作成してください。
|
1 2 3 4 5 6 7 8 9 10 |
@echo off rem 実行パス set dir=%~dp0 rem レポート出力 powercfg sleepstudy /output %dir%sleep_report.html rem すぐ画面が消えないように一時停止 pause |
バッチファイルの説明
rem で始まる行はコメント行です。なんの動作もしません。
まず、dir という変数名に、実行時のパスをドライブ名付きで格納します。
あとは、powercfg sleepstudy でスリープ時を含めた 消費電力の推移のレポートを出よくさせます。出力ファイル名を指定しないと、Windowsフォルダのsystem32 というとんでもないフォルダに作成してしまうので、バッチファイルと同じフォルダに sleep_report.html という名前で出力ファイル名を指定しています。
最後に、出力時のメッセージを確認するため、pause コマンドで、コマンド実行画面を一時停止にしています。
計測の実行
コマンドを入力するのは面倒なので、エクスプローラで、バッチファイルを右クリックして「管理者として実行」をクリックします。
必要に応じて 実行許可をすると、以下のようにコマンドプロンプトが表示されてメッセージが表示されます。何かキーを押すと閉じます。
レポートの表示
レポートはhtml形式で生成されていますので、ブラウザで開きましょう。ダブルクリックすればOKと思います。
グラフ表示
一番上は、時系列でバッテリ残量を示したグラフになります。
スリープ中は、赤ラインで表示されています。
サマリ表示
次に状態(STATE)ごとの電力消費のサマリ表示があります。
ピンク色が、画面OFFや コネクテッドスタンバイ中の表示になります。たとえば22行目は 画面OFFで 6250mW の消費電力、3分間で 320mWh の消費電力量になります。40Wh のバッテリなのでこの速度だと40/6.25 = 6時間ぐらいしか持ちませんね。
23行目はスリープですが 5,558mWの消費電力、18分で1,721mWh の消費電力量となります。これ、パソコン使ってるぐらいの消費電力です。ほぼスクリーンOFFと変わらないぐらい。
個別の解析結果
サマリの下にはそれぞれの行についての個別の解析結果が載っています。
でも、これはあまり良くわからないです。
例えば22行めはスクリーンオフですが、No CS Phase にいたよってことしかわからないです。
このスリープのフェーズについては、マイクロソフトに説明はあります。
下図のような感じで、下に行くほど深いスリープのフェーズに入っているっぽいです。
で、今回は、一番上の状態ってことですね。
23行目に関しては、一番深い Resiliency phase に入っているのですが、補足できないアプリが補足できない要因で電力を使ってることになっています(Power Estimation)。
うーん、よくわからんです。でも、見方としてはこんな感じですよ。
もうちょっとわかりやすい消費電力データと対策効果について
先程、計測のやり方で示したデータでは、スリープ時の消費電力がかなりでかかったのですが、半月ぐらい使っているうちに、少し消費電力が落ち着いてきました。
ネットで調べてもWindows Updateなどが更新しているなどで、原因不明で一定期間だけ消費電力が大きかった例などもあるようでした。
で、暫くすると、かなり落ち着いてきて、以下のように、スリープ中 1800mWぐらいの消費電力となってました。40Wh のバッテリだったら、2Wの消費電力とすると、20時間ぐらいスリープできる計算になります。かなりいいですね。この日は出張だったのですが、スリープ状態で移動しました。19行目のスリープがそれですね。
で、結構、これでも満足だったのですが、念の為、個別データを見てみました。
すると、下図のように、Resiliency Phase で一番深いスリープに入っているのは同じですが、Top Offenders という欄ができていて、一番電力を消費した原因が吊るし上げられていたんです。
ダントツでインテルのオーディオ・コントローラーが悪いってことですよね。
でも、結果的には、デバイスドライバーが悪いわけじゃなく、それを利用しているアプリが悪かったって結果でした。
どこかに明確な記述があったってわけではなく、音声入力を使っているアプリを閉じてスリープしてみたら消費電力が減ったっていう結果名だけですので、まだ不明確ではあります。
経緯としては、コルタナが音声コマンドのためにマイクを監視しているという噂をgoogleから仕入れたので、タスクマネージャーのスタートアップタブから無効にして、それでもだめだったので、更にBandicamをとじたら、無事、スリープ中の電力消費が半分以下になりました。
現時点でのスリープ時消費電力
72行目のときに上で述べたようなアプリの調整を行ったところ、先程試した例では、800mWぐらいの消費電力となってます。
下図の下2つの赤枠ですね。
詳細表示でも、オーディオコントローラが消えています。さらに、ここから消費電力を下げるのは難しそうですが、とりあえず良しとします。
コメント