follow me

[emo] 気になる発熱 / 消費電力 / 通信量について書くよ

2020年の Advent Calendar は、今日で終わりです。
1年も開発に関わってしまったユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。といいながら、赤裸々すぎて赤面してしまった僕ですが、みなさん読んでくれましたでしょうか? (独りAdvent Calendarするつもりは全くなかったのは赤裸々発言です。


emo Advent Calendar 最後の今日は、気になる発熱 / 消費電力 / 通信量 について。


このたぐいの製品を開発する時は、ほぼ何かしら考慮が必要に迫られると思うこの3つについて。
  • 発熱
  • 消費電力
  • 通信量

発熱
発熱は、NXP i.MX8M Mini がどうにかなれば、後は積み上げぐらいの感覚でした。
正確には、NXP i.MX8M Mini と LPDDR4 と eMMC の3つですが。。。
eMMCは、write 量が大きくなければ其処までの発熱は起きないです。(ちなみに、eMMC書き込み負荷で、筐体内温度が +4度 ぐらいですかね。
なので、NXP i.MX8M Mini が 1.8GHz で動作している状態で、熱が逃げてくれれば安心です。

が、予想より熱が籠もりました。(穴もなにも無い筐体だったので、ですよねぇ。ぐらいの感覚ですね。
NXP i.MX8M Mini のデフォルトでは、85度でサーマルスロットリングにより、1.2GHzに落とされるので、音声認識の認識速度に影響を及ぼします。
1.2GHzに落ちてから温度が下がるまでの時間が2分ほど、再度温度が上がるのに3分ほど、もっと周波数を下げれば勿論温度は下がるのですが、そのタイミングの音声認識は諦めないといけなくなります。
常時動かなくても良い製品と、常時負荷が掛かってしまう製品で、この辺りの設計/設定は変わってきますが、今回は大きくは下げれないパターンでした。

とりあえず排熱しないと温度が下がらないので、筐体に穴開けてもらって、ヒートシンクがついて、FANがついて、
負荷と温度から、FAN を on/off というありきたりな方法で対策。

本当は、SoCを筐体外側に配置して、カーボンナノチューブとか使って筐体全体に逃がすか、底面に逃げやすくするとかで、FAN無しとかが理想系な気がします。
FANはやはり全体でみれば壊れやすい部類に入りますし、音が発生してしまいますし。
デザインが先行して筐体が先にできて、ハードが後追いになるプロジェクトの辛い処です。
この辺りは、デザイナーとエンジニアの間の変な溝が生み出す変な無駄ですかね。。。
GHz越えると発熱問題からは逃げられないのは、エンジニア側はみんな予想していると思うのですがね。


消費電力
消費電力を抑える、というのは発熱ともリンクしてくるので、発熱を抑えるのと消費電力を抑えるのは同時に考えるケースが多いです。
BOCCO emo の場合、電源コネクタに microUSB を利用しているので、この時点で実機に求められるのは、5V3Aに収まる事。
ここで、消費電力の大きいと予想されるものを上げたところ。
  • NXP i.MX8M Mini Lite
  • XMOS XVF3000
  • Quectel EC21-J
  • Motor
僕は、この4項目を考えていました。
この中でも XMOS XVF3000 は、データシート上は、最大消費電力大きいのですが、codamaで見ていた時から、実測ではかなり低いのは判明していました。
モーターについては、電流引かれるのは仕方ないとして、一番時間を取られると考えていたのは、NXP i.MX8M Mini でした。
当初、バッテリー搭載の計画も存在していたとの事で、如何に消費電力を抑えるかと。

NXP i.MX8M Mini でまず考えていたのが、負荷に合わせて周波数を下げる、バッテリー状態なら1コアを落としてしまう。
NXP i.MX8M Mini であれば、1.2GHz-1.8GHzで変動してくれます。
もっと下げようと思えば下がる気もしているのですが、発熱は下がるのですが、消費電力の差は大きくなかったので、周波数下げるのは発熱を下げて、FAN等を使わなくてよくするという点ぐらいです。
もっと大きく効果があるかと思ってましたが、1.2GHz程度ではという処でしょうか。
i.MX8MMなのに、config では IMX8MQ となっていて、コレ i.MX8MQ の名前は嵌りました。これは、i.MX8M Quad のことだと思うじゃないですか、(抜いたらビルドできないんですよね。。。
config ARM_IMX8MQ_CPUFREQ
        tristate "NXP i.MX8MQ cpufreq support"
        select PM_OPP
        help
          This adds cpufreq driver support for NXP i.MX8MQ series SoCs.

          If in doubt, say N.
1コアころす方はこちらですね。
CONFIG_HOTPLUG_CPU、依存がいろいろ出るので面倒ですが、発熱は大きく下がるのですが、もともと NXP i.MX8M Mini の消費電力が抑えられていたのもあって、期待値ほど効果が見られませんでした。
config HOTPLUG_CPU
        bool "Support for hot-pluggable CPUs"
        select GENERIC_IRQ_MIGRATION
        help
          Say Y here to experiment with turning CPUs off and on.  CPUs
          can be controlled through /sys/devices/system/cpu.
よくやるこれです。
root@emo-xxxxxx:~# echo 0 > /sys/devices/system/cpu/cpu1/online
root@emo-xxxxxx:~# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

root@emo-xxxxxx:~# echo 1 > /sys/devices/system/cpu/cpu1/online
root@emo-xxxxxx:~# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
BogoMIPS        : 16.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4


通信量
通信量(料)ですが、WiFiだと大抵の場合、ざっくりの見積もりで話が収まることが多いですが、LTE等を利用すると気にされる方が多いです。
通信量で、通信料を気にされますね。
また、通信量を気にするパターンに、2種類あるかと思います。
デバイス側回線視点での通信量、とサーバ側(クラウド側)の通信量。
エンドユーザは主に、デバイス側回線の通信量を気にします。ビジネスよりな繋がりでの場合は、サーバ側(クラウド側)、キャリア回線の通信量を気にします。
どちらにせよ、通信量が小さい方が嬉しいという方が多い気がします。(通信量で稼ぐんだという処は例外ですかね。

また、通信量が小さいと、通信にかかる時間も勿論小さくなる訳で、応答速度の体感が変わってきます。
なので、製品を作る際に、通信量を減らす設計なり開発を行ったりします。
最近では、デバイス側主動での http や https を使った REST API 以外に、MQTT や WebSocket を流用する事が増えているかと思います。
(トンネルを先に作って、トンネルで圧縮とかしてしまうとかいう荒業をしている製品もありますが。。。たしかにそれも手段の1つですが

BOCCO emo では、 WebSocket を併用する事で、応答速度や、通信量削減を実現しています。
MQTT と WebSocket、この2つが世の中的にも候補に上がりやすく、比較検討となるものと思いますが、WebSocket の大きな利点は、企業等で http やhttps を通す設定を行っている Firewall が多いという点でしょうか。WebSocket はポート番号が共通であり、接続フローも同じなので、多くの場合 Firewall を通過する事ができます。
まぁ、企業の場合、セッション時間が長いと切るというのもあるので、その切断に対応しておかないとという話も出てきたりしますが。
企業利用が見込まれる場合に、Firewall の追加設定(申請) 等が不要となるのは、大きなメリットがあります。

メモリの消費量、エンジンの軽量さでいえば、個人的には MQTT が有利だと感じています。(利用する実装により違うので、一概には言えないのですが
マイコンで搭載メモリが小さいのであれば MQTT、ネットワークの疎通を考えて WebSocket という使い分けかなと個人的には考えています。
あとは、サーバ側の構築/運用の手間を考えないといけないですね。
サーバ側の負担は、MQTTの方がラクというのが個人的見解。(最近サーバ側担当しないのでアレなのですが。

あと、MQTT や WebSocket を利用した場合、双方向通信になるので、応答速度の改善度合いは大きいです。
双方向といってもセッションを張るのは、あくまでデバイス側で、トンネルが出来たらそのまま使うというだけですが。
通信量を減らす以外にも MQTT や WebSocket を利用するメリットは大きいです。


emo Advent Calendar 2020、25日目でした。
次は 何かネタになるもの を書きたいと思います。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。むきゅっ!
でわ、また。
[emo] 気になる発熱 / 消費電力 / 通信量について書くよ | 0 件のコメント | アカウント登録
サイト管理者はコメントに関する責任を負いません。