Xperia Z5でガクガクかつ通信エラーで遊べない問題の原因と対処法<その1>

愛機のXperia Z5で冬の間は快適に遊べていたPokemon Goが、春以降、カクカク・ガクガクになって、かつ、通信エラー連発でまともに動かない状況で困っていましたが、ようやく現象のおおよその原因と対処療法ですが対処法が分かりました。
CPUであるSnapdragon 810の仕様にも関係していそうなので、他のXperiaや他メーカーでも同様の現象があるなら、この方法で改善する可能性はあるかもしれません。Pokemon GoのGoogle Playのレビューを見るとネットワークエラー連発で遊べないと書いている人がかなりいますしね。

◎発生する症状 → 気温18〜27度くらいで発生しやすい!?

元々この現象、とても不思議でした。寒い冬の間に調子が良いのは分かるとして、冬の間、室内やポケットの中でスマホがチンチンに熱くなっても、ちょっと動作が重いなと思うことはあってもガクガクでまともに動かない、という記憶はほとんどなかったからです。
だんだん春になり、気温が暖かくなってきたところ、突然、ガクガクになってまともに動かない現象が発生し、ポケモンを捕まえるのもジムを攻めるのもままならない、という症状が発生。まともに動かないと毎日ストレスです。

前述のようにもっと熱いときでも動いていたので不思議に思いつつ、熱が原因だろうと思い、TPU素材のカバーで熱がこもっているせいだろうと、カバーの一部をカットしてスマホ裏面の特に熱い部分の放熱を促すようにしたところ……、前にも増してガクガク現象が発生する事態に!

ある一定の温度の範囲内でおかしいということに気づき、さらなる調査を行いました。

◎CPUの一部のコアだけ100%になっている

何が起きているのか現象を探るため、CPU使用率を表示するアプリを入れて監視しても、特に症状の発生前後でほとんど変化がありません。(20%くらい)
そこで、Snapdragon810はオクタコアであるため、各コアの使用率が分かるアプリを入れてみました。すると、症状がおきていないときはCPUの各コアが平均して動いているのに、症状が起きている間は、なぜか5つ目のコアだけ100%になっていることに気づきました。

コアごとの使用率を通知バーに表示してくれるアプリ CPU 使用率モニター CPU Stats
その他、指定したセンサーの温度情報をグラフ表示してくれる Simple System Monitor というアプリも入れて監視しています。


↓ 5番目のコアだけフルになっていて、他のコアは働いていない!

snapdragon810の仕様を簡単に調べると、オクタコアと言っても内部は、性能も消費電力も高いA57の4コア(最大周波数2.0GHz)、性能も消費電力も低めのA53の4コア(最大周波数1.5GHz)が搭載されて、合計で8コアということのようです。
どうもこれがこのガクガク現象のポイントのような気がします。

◎温度と動作を設定する thermal-engine.conf

調べていくと、Androidの熱制御の設定ファイルとして、/etc/themal-engine.conf というファイルがあることに気づきました。
そこから関連しそうな部分を抜粋したのが以下です。

[emmc_therm__0.DEFAULT]
algo_type monitor
sensor emmc_therm
sampling 1000
thresholds 43000 47700 48900 50200 51400 52000 52600 53200 53600 54000 54500 55000 55500 55900 56300 56800
thresholds_clr 40000 43000 47700 48900 50200 51400 52000 52600 53200 53600 54000 54500 55000 55500 55900 56300
actions cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall
action_info 1555200+1958400+0+0+1+1+630000000+255+2+0+100000+0+0+0 1555200+1248000+0+0+1+1+630000000+209+3+0+100000+0+0+0 1478400+864000+0+1+1+1+630000000+171+3+0+100000+0+0+0 1478400+384000+1+1+1+1+630000000+141+3+0+100000+0+0+0 1344000+384000+1+1+1+1+630000000+115+3+0+100000+0+0+0 1344000+384000+1+1+1+1+630000000+95+3+0+100000+0+0+0 1248000+384000+1+1+1+1+630000000+78+8+0+100000+0+0+0 1248000+384000+1+1+1+1+630000000+64+8+0+001800+0+0+0 960000+384000+1+1+1+1+630000000+52+9+0+001800+5+0+0 960000+384000+1+1+1+1+450000000+44+12+0+001800+5+0+0 864000+384000+1+1+1+1+450000000+44+12+0+001800+5+0+0 864000+384000+1+1+1+1+390000000+44+12+1+001800+5+0+0 768000+384000+1+1+1+1+390000000+44+12+1+001800+5+0+1 600000+384000+1+1+1+1+180000000+44+12+1+001800+5+0+1 460800+384000+1+1+1+1+180000000+44+12+1+001800+6+0+1 384000+384000+1+1+1+1+180000000+44+12+1+001800+6+0+1

[emmc_therm__1.DEFAULT]
algo_type monitor
sensor emmc_therm
sampling 1000
thresholds 63000 80000
thresholds_clr 56800 63000
actions cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall cluster0+cluster1+hotplug_4+hotplug_5+hotplug_6+hotplug_7+gpu+s_backlight+battery+modem+s_cam_ltb_tim+s_cam+s_fs1seg+s_synccall
action_info 384000+384000+1+1+1+1+180000000+36+13+1+001800+6+3+1 384000+384000+1+1+1+1+180000000+36+13+1+001800+6+4+1

Androidの仕様書やソースを確認したわけではないので、書かれている内容と実際の挙動からの推察ですが、1秒に1回、emmc_therm の値でCPUの周波数や動作する数を制御しているように見えます。これを見やすく表にものが以下です。

しきい値
(℃)
解除
しきい値
(℃)
CPU
クラスタ0の
周波数(GHz)
CPU
クラスタ1の
周波数(GHz)
コア5
停止
コア6
停止
コア7
停止
コア8
停止
43.0 40.0 1.56 1.96 0 0 1 1
47.7 43.0 1.56 1.25 0 0 1 1
48.9 47.7 1.48 0.86 0 1 1 1
50.2 48.9 1.48 0.38 1 1 1 1
51.4 50.2 1.34 0.38 1 1 1 1
52.6 52.0 1.25 0.38 1 1 1 1
53.6 53.2 0.96 0.38 1 1 1 1
54.5 54.0 0.86 0.38 1 1 1 1
55.5 55.0 0.77 0.38 1 1 1 1
55.9 55.5 0.60 0.38 1 1 1 1
56.3 55.9 0.46 0.38 1 1 1 1
56.8 56.3 0.38 0.38 1 1 1 1

実際の挙動としては、emmc_therm の温度が48〜49度をウロウロしてコア5が100%となりガクガク現象が発生していることが多く、50度を超えてくるとコア5が使用されなくなり、コア1〜4が仕事をし始め、画面は急にヌルヌルに戻り、挙動が安定します。
つまり、黄色く塗ったコア5のみが生きているときの状態がNGということです。
よって、この設定ファイルの見方は、47.7〜48.9度の間に発動されるのではなく、48.9度以上になると、47.7度未満になるまで発動される、と考えるのが自然です。逆にいうと、50.2度を超えると48.9度未満になるまではコア5は生きてきません。
コアのシャットダウンや起動にもロスがあるため、温度がしきい値前後をフラフラしてコアの起動・シャットダウンが繰り返されないようにする仕組みと推察します。
なお、43度のところでCPUクラスタ1の最大周波数を1.96GHzと設定しているところがあるので、おそらく、クラスタ0側がA53のCPU(性能が悪い方)、クラスタ1側がA57のCPU(性能が良い方)ではないかと推察されます。温度が高いとせっかくのSnapDragon810の性能は全然活かされないということですね。。

なぜコア5が生きているだけガクガク現象になるのかは、XperiaZ5の制御の問題なのか、ポケモンGOの作りの問題なのか、分かりません。
仮説として考えたのは、XperiaZ5側はメインスレッドを高速CPUであるコア5〜8側で動作することになっていると仮定して、ポケモンGO側の通信やゲーム制御のスレッドはメインスレッドにあると仮定します。そして、ポケモンGOはサブスレッドからの要求もメインスレッドが最終処理をすると仮定します。
上記の仮定の元、emmc_therm が48.9度を超えると、メインスレッドが動くA57側のコアは1つしか動かず、かつ、周波数が0.87GHzに押さえられています。他のスレッドは1.48GHzで高速に動いており、それらからの要求でメインスレッドがパンクし、要求をこなせない状況に陥る。サブスレッドは要求に対する応答が来ないため、待ちとなり、コア1〜4側はCPUがあまり稼働しない状況に陥る、といった状況を想像しました。(想像です!)

◎まるでアイドリングが安定せず暖気ができないバイクのよう

この現象はタチが悪く、温度が低い状態からポケモンGOを立ち上げると、CPUがぶん回されるので1分程度で温度がすぐに49度くらいになります。
そして、この現象が発動されると、コア5以外のコアはあまり動かなくなるので、温度が下がります。温度が下がり、47.7度に落ちるとコアがまた動き出し、温度が上がり、またすぐに現象が発動されます。
よっていつまでも現象が続く状態になり、いつまでもゲームがまともに動きません。

長くなってきたので、対処方法は次の投稿で書きたいと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です