Armadilloフォーラム

サスペンドへの移行時間について

minaba

2023年5月26日 11時39分

Armadillo-IoT G4についての質問です。

質問:
Suspend-to-RAM、Suspend-to-Idle、(及びpower-off)を発行した際の状態移行に要する時間はわかるでしょうか。
状況によって幅があるとして、最大何秒、あるいは何ミリ秒?かをLANモデル、LTEモデルそれぞれについて知りたいのですが。

また、状況によって幅がある場合、その要因として何が考えられるでしょうか。

コメント

at_mizo

2023年5月31日 9時24分

溝渕です。

> 質問:
> Suspend-to-RAM、Suspend-to-Idle、(及びpower-off)を発行した際の状態移行に要する時間はわかるでしょうか。
> 状況によって幅があるとして、最大何秒、あるいは何ミリ秒?かをLANモデル、LTEモデルそれぞれについて知りたいのですが。

一般論ですみませんが、LinuxはリアルタイムOSではないので最大応答時間が定義されていません。ただ、今迄の私の経験上は、suspendの完了が数秒単位で待たされる事はありませんでした。

参考までに、WLANモデルで実測した結果は次の通りですので参考にしてください。

Suspend-to-RAM: 0.54s
Suspend-to-Idle: 0.21s

armadillo:~# echo mem > /sys/power/state
[   35.270819] PM: suspend entry (deep)
[   35.305016] Filesystems sync: 0.030 seconds
 :snip
[   35.808778] CPU3: shutdown
[   35.815807] psci: CPU3 killed (polled 0 ms)
armadillo:~# echo freeze > /sys/power/state
[   68.311839] PM: suspend entry (s2idle)
[   68.323030] Filesystems sync: 0.007 seconds
 :snip
[   68.329535] Freezing remaining freezable tasks ... (elapsed 0.028 seconds) done.
[   68.523658] fec 30be0000.ethernet eth0: Link is Down

上記ログ取得時には、suspend時にconsoleを停止しないよう、起動パラメータ(U-Boot環境変数の"optargs"です)に以下を追加しています。
no_console_suspend=1

また、次のようにログレベルを上げています。
echo "7 7 7 7" > /proc/sys/kernel/printk

> また、状況によって幅がある場合、その要因として何が考えられるでしょうか。

少なくとも以下の要因で多少の前後はある思います。

* suspend要求時点でのOSの状態(非リアルタイムOSと同意)
* 動作しているデバイスの数
* 動作しているデバイスの種類(suspendにかかる時間はデバイスにより異なる)

恐らく期待されていた回答とは異なるとは思いますが、参考になれば幸いです。

minaba

2023年5月31日 13時36分

溝渕さん、

minabaです。
ご回答ありがとうございます。十分、参考になりました。

感覚的には1秒以内ぐらいに思っていましたが、知らない要因があって、場合によっては数秒かかる事もあるというような事がないか確認したくて質問させていただきました。質問の仕方が良くなかったかもしれません。実測値の提示ありがとうございます。

at_mizo

2023年5月31日 13時46分

溝渕です。

> 感覚的には1秒以内ぐらいに思っていましたが、知らない要因があって、場合によっては数秒かかる事もあるというような事がないか確認したくて質問させていただきました。

先に述べました通りリアルタイムOSではない以上、最長応答時間の定義が無いので、数秒かかる事が無いとは言えません。これはsuspendに限った話ではなく、例えば各種プログラミング言語で最初に良くサンプルとして示されるHello worldでも、描画されるまでの最大時間を定義できません。しかし、現実的にHello worldが描画されるまで数秒以上もかかるような状況を目にする事は恐らくそれ程多くないと思います。

上記と同じ理由で、現実的に(粗悪なデバイスドライバが動いていたり、極端にハードウェアリソースに負荷がかかっている状態等を除き)それ程長時間待たされる事は無いと思います。

> 質問の仕方が良くなかったかもしれません。

いえ、そんな事無かったです。お気になさらないでください。

minaba

2023年6月1日 14時20分

溝渕さん、

minabaです。
承知しました。下記の理解です。

最大応答時間は規定できない以上、確率的にはほぼ0でも数時間かかる事も原理的には有り得る。
秒のオーダーというのはあくまで経験則であり、保証できるものではない事は、設計上踏まえておく必要がある。

どうもありがとうございます。

at_dominique.m…

2023年5月31日 9時44分

minabaさん、

マルティネです。

横からすみあせん、LTE モデルについても情報が少しあります。

> LTEモデルそれぞれについて知りたいのですが。

Armadillo IoT G4 の LTE モデムの場合は USB の接続を一旦切っていますので、その接続が復帰して networkmanager が再び ppp (LTE経由のネットワーク)接続をするまで少し時間がかかります。
(数回ためしたら20秒程度でしたが、これも幅がでる事もあると思います。)

ネットワーク以外はすぐにLAN/WLANモデルの様に起きますので、wakeup後に接続が必要な場合にリトライを実装してください。

(ちなみに LTE の接続自体は切っていませんので、SMS受信での wakeup は使えます。)

よろしくお願いします。

minaba

2023年5月31日 13時40分

マルティネさん、

minabaです。
追加のコメントありがとうございます。

お寄せいただいた情報は、復帰時間についてでしょうかね。
溝渕さんにご回答いただきましたが、今回は落ちるまでの時間について質問させていただきました。

とはいえ、貴重な情報ありがとうございます。