2013年7月27日土曜日

ART-Linuxの実験 プロセス起動のリアルタイム性

さてサンプルで1secに1回プログラムが起きるようにしてみました。さて、他のプログラムが動いていたらどうなるでしょう?一般的には遅れが発生すると予想されます。

1.YouTubeを同時に動かす
CPU負荷が20%以下にしかなりませんが、サンプルプログラムの起動タイミングにはまるで影響がでませんでした。
これでは負荷が軽すぎるようです。

2.CPUを100%使用するfor-loopだけのプログラムを同時に動かす。
ところがこれでもサンプルプログラムの1sec毎の起動には影響がでません。(負荷をかけるプログラムの実行時間がサンプルプログラムと同時に動かすと若干realの実行時間が多くなりますので、負荷プログラムが同時に動くことによる影響はでているようです)

3.起動周期をかえる
ここまでAPは動かさず、ずっとBSPで実験してきました。BSPでも結構リアルタイム性は高いような気がしてきましたが、なんか変です。
ふと気づいたのが、サンプルプログラムが1sec毎のタスク起動だということです。実際にこれを使うプログラムなら1~10ms毎のタスク起動で使うでしょう。そこでサンプルを10ms毎のタスク起動にしてみました。(100回だったloopは10000回になります)普通にまたコンソールに出力したら、そこでボトルネックになりそうなので、ファイルへリダイレクトします。

(最終行)
[9999] 99.971077

ちょっとこれは予想外な値になりました。ほかのタスクは何も動いていません。(gnome-desktopは動いていましたが)artのtimerがどういう仕組みになっているのかわかりませんが、10ms毎と指定しているのに、ほんの少し早くトリガがかかってしまうようです。

4.APで実験する
同じサンプルをAP側で実行してみました。

(最終行)
[9999] 99.99090

さすがにさっきよりは正確ですね。それでもぎりぎりという感じです。

Core2やNVidiaのPCだとARTのタイマは遅れ気味になるという話を別のところで聞いたのですが、これだと逆に早くなってない?という感じです。ただまあ、あきらかにAPを使うシステムの方がリアルタイム性にはすぐれていそうな雰囲気ではあります。
ただART-linuxのデフォルトのタイマ分解能は1msだとのことなので、10ms周期のタスク制御がぎりぎりかなあという感じではあります。(元がLinuxベースなのでしょうがない?

PS
先ほど「タイマ分解能」と書きましたが、正確には実時間割り込み周期の最短時間のことです。特に設定せずに実験していましたが、ちょっと気になって設定して同じことをしてみました。
grubで起動するときに、ART=***というオプションを追加します。単位はusですので、デフォルトはART=1000だと思っていました。これをART=500で起動してみると明らかにタイマ割り込みが遅くなってしまいました。(BSP、AP両方とも)割り込み処理の負荷が耐え切れなくなったのか?と思い、ART=1000にしてみました。これでもとに戻るかと思ったら、ほぼデフォルトには近くなりましたが、タイマの精度がよくありません。
内部タイマで実験してもそろそろ限界のようなので、外部で計測してみないとだめのようです。(あるいはもっと長時間計測用プログラムを動かして、誤差の蓄積を多くする)

0 件のコメント:

コメントを投稿