KernelTrap経由で、LatencyTOPを知りました。
LatencyTOP focus on type
that causes audio skipping and desktop stutters. Specifically, LatencyTOP
focuses on the cases where the applications want to run and execute useful
code, but there's some resource that's not currently available (and the
kernel then blocks the process).
う～ん・・・RTOSではレイテンシというのは、例えばタスクスイッチにかかる時間を指したりするんですよねぇ。例えば、セマフォを待ってるタスクAが居るとして、別のタスクBがセマフォを解放してからタスクAにCPUがスイッチされるまでの時間です。別の例としてはハードウェア割り込みの要因となる信号がアサートされてから、割り込みハンドラのエントリポイントに突入するまでの時間とか。
この割り込みのレイテンシはリアルタイム制御システムではリアルタイム性能の根幹に関わるので、最大値だけでなくバラツキも重要です。一般的にバラツキがなぜ重要なのかについては統計について調べてください。
さて1時間テストしようが、24時間、1ヶ月テストしようが、そこで得た最大値は、フィールドでの最大値を保証してくれるものではありません。簡単に言えば、標準偏差が取れれば、それを何倍かしておけばフィールドでのソフトウェア故障発生確率をＸＸＸ以内に抑えることができると期待しても良いと言うことなのです。6倍に設定したのが、シックスシグマですよ。
＃標準偏差と分散をない交ぜにして騙ってますんで、鵜呑みにしないようにお願いしますよ。
おそろしく脱線しましたが、標準的にレイテンシがどう呼ばれるのかは正直よく分かりません。割り込みハンドラのレイテンシも、場所によっては”遅延”とだけ表現されることも多かろうと思いますし。
知ったかぶりで統計のことを長々と書いたのは、このインテルのひと？も平均値や最大値を並べているからです。平均性能で評価を続ける限り、オーディオのプチノイズや、ビデオのカクカクは決して解消されることは無いでしょう。余程のオーバースペックにする必要があります。しかもオーディオはハイデフ時代、ビデオもハイデフでどんどん処理帯域が増している世の中です。
リアルタイム性能は、遅延のバラツキに現れます。いや、あえて書きましょう。品質と言うのは、絶対値で評価してはイカンのです。バラツキと感度で量るべきなのです。と品質工学かぶれなことも書いておきます。
レイテンシ、乱暴に書けば遅延はは大きくても構わないのです。なぜなら、CPUパワーが足りているという前提においては、オーディオとビデオがおなじくらい遅延しても、プチノイズやカクカクにはならないのです。問題は遅延が大きくばらつき、オーディオやビデオの処理単位、例えば512msecに迫ると情けない現象が起こるのです。
CPUパワーが足りなければレイテンシを評価すること自体がナンセンスですし、レイテンシの最大値/平均値だけを評価して改善しても意味が無いことの説明、分かっていただけたでしょうか。
まぁたぶん、標準偏差や分散を求める機能もきっと入っていることでしょう。入って無くてもすぐにどこかのお偉いさんが提案して取り込まれるはずです。
(2008.01.21追記)
もんたクンのページに分かりやすい解説がありました。けれど図はデッドリンクになってます。まぁもんたクンの状況とはそんなもんです。
コメント