プロセッサの高速化がリアルタイムシステムの期限を逸してしまうのはなぜですか？

Question

これについて少し混乱します。プロセッサを高速化すると、タスクを実行するのに時間がかかりませんし、それだけ早く締め切りになるでしょうか？

おかげ

Answer 1

答えは、スピードが速いために新しいリソースの競合が発生する可能性があるということです。これは、Grahamの異常として知られています。スケジュールの長さが最小になるようにマルチプロセッサ上でスケジュールされたタスクセットの場合、プロセッサの増加、実行時間の短縮、または優先順位の制約の弱まりは、スケジュールの長さを長くする可能性があります。目的（スケジュールの長さを最小にする）に注意してください。しかし、タスクに期限があり、目的がすべてのタスクの締め切りを満たすことであれば、異常は容易に真となることが示されます。これは、オペレーティングシステムに関するいくつかの書籍の例のイラストで十分に文書化されています。

も参照してください：

• ・アンダーソン、B; Jonsson、J。 「Preemptive multiprocessor scheduling anomalies、Parallel and Distributed Processing Symposium」、Proceedings International、IPDPS 2002、Abstracts and CD-ROM、vol。、pp.12-19、2002。doi：10.1109/IPDPS.2002.1015483
• Grahamm RL、 "Bounds on Multiprocessing Timing Anomalies"、SIAM Journal on Applied Mathematics、Vol。 17、No.2（1969年3月）、pp。416-429。

Answer 2

多分 - しかし、プロセッサ（例えば、キャッシュ）をスピードアップするために使用される多くの技術はまた、彼らはより予測します。これらの手法のほとんどは最悪の場合を犠牲にしての平均値をに改善します。たとえば、キャッシュを使用すると、最悪の場合、メモリからのフェッチはキャッシュなしの場合よりも遅くなります。メモリからフェッチする時間は、があります。データが存在するかどうかを確認するためにキャッシュを検索する時間があります。

残念なことに、リアルタイムスケジューリングでは、平均的なケースではなく、の最悪のケースが主な原因です。そのような最適化によってほとんどの場合、ほとんどのコードが高速化されますが、リアルタイムシステムのデッドライン。

Answer 3

依存...プロセッサの高速化は、システムの他の部分（メモリアクセス時間、伝搬遅延など）に影響を与えません。プロセッサの速度を上げると、これらのことがタスクの処理時間の大部分を占めるようになります。

プロセッサの速度を上げると、システムのセットアップ方法によっては、クロックサイクルで伝播が繰り返され、再試行によって遅延が発生する可能性があります。

デッドラインがプロセッサに基づいてカウンタまたはタイマーに関連付けられている場合は、カウンタのメインメモリアクセスがないため、それに比例して増加します。

いずれかの要因が、設定によって異なります。

Answer 4

このようなことが起こり、ダグラスは既にGrahamsの異常を説明しました。私は少しの例でそれを説明しようとします。

複数の並行タスクと通信チャネルなどの固定速度の共有リソースを扱う場合、異常が発生します。

リアルタイムシステムとの関連で、このための良い例はデータ取得です。アナログ/デジタル変換器からxミリ秒のデータを読み取る必要がある場合は、CPU速度に関係なく、常にxミリ秒かかります。私の例では、これを「IO時間」または「IOタスク」と呼びます。

今すぐ次のシナリオを検討してください：

あなたはで構成されて一つのタスク（A）があります。

• 4ミリ秒のCPUの計算
• 4ミリ秒IO時間（データを保存）

を

ハードウェアイベントによって開始される第2のタスク（B）は、

• 4ミリ秒IO時間（荷重データ）
• 2ミリ秒のCPU時間

は、第2のタスクは、資源を共有しているミリ秒3.

IOとCPUで開始されます。これらは並列で実行できますが、IOまたはCPUは一度に1つのジョブしか処理できません。このため

一つの可能​​なスケジュールは次のようになります。CPUは倍の速度で実行されるように

timestamp: cpu/io job: 
--------------------------------------------- 
t=0   event <--- hardware event triggers task-a 
t=0   cpu  start of task-a (4 ms) 
t=3   event <--- hardware event triggers task-b 
t=3   io  start of task-b (4 ms) 
t=4   cpu  task-a done 
t=7   io  task-b done 
t=7   io  start of task-a (4 ms) 
t=7   cpu  start of task-b (2 ms) 
t=9   cpu  task-b done 
t=10   io  task-a done 

は、今、私たちは、CPUパワーを倍増：

timestamp: cpu/io job: 
--------------------------------------------- 
t=0   event <--- hardware event triggers task-a 
t=0   cpu  start of task-a (2 ms) 
t=2   cpu  task a done 
t=2   io  start of task a (4 ms) 
t=3   event <--- hardware event triggers task-b, but can't start 
          because io-bus is busy. Must wait. 
t=6   io  task a done 
t=6   io  start of task b (4 ms) 
t=10   io  task b done 
t=10   cpu  start of task b (1 ms) 
t=11   cpu  task b done 

あなたが見ることができるように、 CPU速度の向上により、遅いCPUシナリオと比較して2つのタスクが1ミリ秒後に完了しました。これは、ハードウェア・イベントが発生している間、固定速度共有リソースがビジーであったためです。

これはほんの1ミリ秒ですが、これらは加算され、期限が間に合わない可能性があります。