Windows Info 第17回

Win 8.1で利用できるInstant Goのトラブルを解決する

実際にトラブルがあるとどうなる？

　実際にConnected Standbyのトラブルを見てみようのグラフでは、充電終了後に利用し（最初のグレーの下に向かう線）、電源ボタンでスリープにしたものの、その間アクティブな状態が続いていた。赤い線の部分は平らな部分もあるものの、急激に降下している部分もある。スリープ状態だが、完全なConnected Standbyにはなっていないようだ。

SleepStudyレポートの先頭部分。バッテリ残量（縦軸）と時間のグラフ、およびスリープ期間のリストがある。グラフやリストで赤い部分は「High System Activity」、オレンジの部分は、「Moderate Sytem Activity」で、多少電力消費がある状態、緑色は「Low System Activity」で完全に低消費電力状態になっていることを示す

　そのうちの1つの領域を見てみることにしよう。グラフ下のリストをタップすれば、それぞれのスリープ期間の詳細表示へ移動できる。下の図を見ると、この期間、低消費電力状態にまったく入っておらず、1時間あたり554mWの電力を消費していることがわかる。次の領域は、Connected Standby期間中のDRIPS（Deepest Runtime Idle Platform State）の連続期間を集計したヒストグラムだが、ここにはなにも表示されていない。これは、DRIPSに入った期間がまったくないことを示す。

グラフ右側の緑の部分の2つ前のスリープ期間の詳細表示。スリープ状態だが、低消費電力状態には入っておらず、消費電力が高い状態になっている。原因はGPUが動作しているため

　さらに下を見ると、このスリープ期間では、GPU（Intel(R) HD Graphics 5000）が100%アクティブだったことがわかる。つまり、GPUがアクティブであったために、低消費電力状態に入ることができなかったのである。

　実は、これはUSB接続型のディスプレー用にインストールされたDisplay Link社のドライバがGPUを利用しており、これがずっとGPUをアクティブにしていたためにConnected Standbyに入ることができなかったのである。このドライバは、外部にUSBディスプレイが接続されていない場合でも、GPUを利用した状態になることが報告されている。

　これをアンインストールしたあと、スリープ状態しても、グラフは依然、赤の線のままだった。しかし、94%が低消費電力状態に入っており、ドライバアンインストール前よりも消費電力は小さくなっている。DRIPSヒストグラム（下図）を見ると、32秒（32s）のところに高い頻度があることが示されている。これは、30秒に1回、通信のためにシステムがアクティブになるため、DRIPS期間の長さを集計するとこうなるわけだ。

問題があったドライバを削除した直後のスリープ期間。全体の94％が低消費電力状態にあるものの、DRIPSヒストグラムを見ると、32sのところだけでなく16sのところにもグラフが立っている。これは、30秒周期で起動された処理が長引き、低消費電力状態に入る時間が短かくなってしまったのだと思われる

　ただし、この時点では、低消費電力状態は全体の94％でしかない。これは、ヒストグラムの16秒のところがゼロになっていないため、処理が長引き、30秒の一回のサイクルの中で、その半分程度の時間がなんらかの処理のために使われてしまったことを意味する。これは実際にはWAN（LTE）デバイスが原因だった。LTEはまだ消費電力が大きく、電波環境によっては、大きく電力を消費してしまうことがある。WANデバイスをオフにすると、次のスリープでは緑色の状態に復帰した。

　なお、Connected Standby中は、緊急度の高いWindows Updateのダウンロードやタイル更新、メール、SNSの更新チェックなど、さまざまな処理が重なる可能性もある。このため、システムとしてはConnected Standbyになったとしても、必ずしも「Low System Activity」になるわけではない。

　ヒストグラムの下の表は、アクティブになっていたデバイスのリストで、この表では、CPUが一番長く3％の時間アクティブになっていたとことを示す。WANデバイスに未契約のSIMが装着されていたため、なんらかの処理が発生したか、あるいは、WANデバイスとは無関係になんらかの処理が行なわれた可能性もある。

　ネットワークデバイスなどは2％程度になることは普通で、CPUが上位に来るのは、CPUの負荷が多少高く、処理時間が長くなってしまったのだと考えられる。なお、この表にあるデバイスはそれぞれのタイミングで動作しているので、必ずしもActive Timeの合計が低消費電力状態になかった期間と一致するわけではない。また、この表に表示されている「BI」とは「Background Infrastructure」の略で、モダンUI環境でストアアプリに対して提供されるバックグラウンド処理のメカニズムを指す。具体的には、メールチェックやタイル更新などの処理のために使われた時間を示すものだ。

　さらに、次のスリープ期間では、グラフの線は緑になり、期間の97％が低消費電力状態になった。この状態で6時間のConnected Standbyで電力消費量はバッテリ容量の1％（合計558mWh、1時間あたり92mW）となっており、メールなどの受信を行いながらも、かなり低消費電力状態にあるといえる。

問題を取り除いたときのスリープ期間。全体の97％が低消費電力状態で、ヒストグラムも32sのところにだけグラフが立っている。一時間あたりの電力消費は92mW、6時間で1％しかバッテリを消費していない。CPUのアクティブ期間は1％となり、GPUはほとんどアクティブになっていない

　もし、Connected Standbyが有効な機種を持っているなら、一回は、コマンドを使って、レポートを生成し、Connected Standbyの状態を確認しておいたほうがいい。もっとも、今回の例のようにスリープ中でもアクティブなデバイスがあると、復帰したときに明かな電力消費がある。逆に、スリープになにか異常を感じたら、Powercfgコマンドを使いsleepstudyレポートを出してみるといいだろう。