9

GNU/Linux マシンでは、「リアルタイム」(サブ ミリ秒のタイム クリティカル) タスクを実行したい場合、ほとんどの場合、カーネルにパッチを適用して適切なサポートを公開するという、時間のかかる複雑で問題が発生しやすいプロセスを実行する必要があります[ 1] [2] .

最大の問題は、リアルタイム タスクが最も有用な多くのシステムが、これらのパッチを機能させるための基本的なハードウェア要件、つまり高解像度タイマー周辺機器を備えていないことです。または、そうである場合、それはハードウェアに固有であるため、ケースバイケースでパッチに具体的に実装する必要があります。これは、CPU/命令のクロック レートが必要な時間の粒度を提供するのに十分な速さを超えている場合でも当てはまります。

それで、私の質問は、上記のリアルタイムの目標にできるだけ近づくための最良の2位の方法/トリックは何ですか? アプリケーションのソース コードで簡単に実行できること。基盤となるハードウェアや「カーネル ハッキング」についての詳細な知識は必要ありません。

プロセスの優先順位を上げ、「クリティカル」タスクのために追加のスレッドを開始し、(C で) nanosleep() のバリアントを使用することは、私がこれまでに思いついた最も見栄えの良い答え/トリックです。もっと見つけたいと思っています。

4

4 に答える 4

4

sched_setscheduler（2）とその仲間は、2つの異なるソフトリアルタイムスケジューラー、SCHED_FIFOSCHED_RRを使用できるようにします。これらのスケジューラーの下で実行されているプロセスは、通常のプロセスよりも優先されます。これらのプロセスがいくつかあり、それらの間の優先順位を制御している限り、実際にはかなり下降したリアルタイムの応答を得ることができます。

コメントで要求されているように、SCHED_FIFOとSCHED_RRの違いは次のとおりです。

「リアルタイム」スケジューラーでは、最大100の異なる優先順位があります（POSIXは32の異なるレベルのみを必要とするため、sched_get_priority_min（2）とsched_get_priority_max（2）を使用して実際の数を取得する必要があります。スケジューラーは両方ともプロセスをプリエンプトすることによって機能します優先度の低いスレッドの場合、違いは、同じ優先度のタスクを処理する方法にあります。

SCHED_FIFOは、先入れ先出しスケジューラです（そのため名前が付けられています）。これは、実行キューに最初にヒットしたタスク、実行が完了するまで実行が許可されるタスク、実行キューのスペースを自発的に放棄するタスク、または優先度の高いタスクによってプリエンプトされるタスクを意味します。

SCHED_RRは、ラウンドロビンスケジューラです。これは、同じ優先度のタスクは特定の時間クォンタムでのみ実行できることを意味します。このタイムクォンタムがなくなったときにタスクがまだ実行中の場合、タスクはプリエンプトされ、実行キュー内の次のタスク（同じ優先度）は、そのタイムクォンタムまで実行できます。SCHED_FIFOと同様に、優先度の高いタスクは優先度の低いタスクをプリエンプトしますが、優先度の高いタスクによってプリエンプトされたタスクの再実行が許可されると、クォンタムに残っている時間だけ実行が許可されます。タスクのタイムクォンタムを設定する方法については、 sched_rr_get_interval（2）のNoesセクションを参照してください。

于 2013-03-21T15:34:28.143 に答える
4

MRG

RT 以外のカーネルでサブミリ秒を保証するのは難しいでしょう。ここ数年で多くの非常に優れた作業が行われたことは知っていますが (たとえば、大きなカーネル ロックがなくなったなど)、それを保証するにはまだ十分ではありません。

CERN と Fermilab のフレンドリーな原子論者から Scientific Linux を見てもらうことができます。これにより、MRG をインストールすることができ (私のリンクを参照)、PREEMPT_RT パッチのプレパック セットアップが提供されます。

または、お金があれば、Redhat MRG を入手できます。これは、PREEMPT-RT パッチが組み込まれた完全にサポートされた Linux ディストリビューションであるため、問題が発生しやすいカーネルのパッチが不要になります。

問題は、Redhat が多額の料金を請求することです (インストールごとに年間 3000 ドル)。最大の顧客の 1 つは高速取引の投資家であり、まだたくさんのお金を持っているため、年間 3,000 ドル/箱がドアの外に出ていることに気付かないだろうと彼らは転落したと思います.

MRGとの付き合い方

私は MRG で (上記の両方を使用して) かなりの作業を行いましたが、これはかなり優れています。ストックカーネルの割り込みサービスルーチンをスレッドに置き換えて、割り込みを処理します。つまり、IRQ スレッドよりも高い優先順位でソフトウェアを実行できるということです! これは、アプリケーションでサブミリ秒のレイテンシーを保証することに近づきたい場合に行う必要があることです。

MRG がメインライン カーネルに徐々に移行しているように見えますが、これは良いことだと思います。いずれメインになる日が来るかもしれません。

その他の落とし穴

最新の CPU の熱管理は、本当に頭の痛い問題です。CPU が少しウォームアップしたという理由だけで、システム管理割り込みが (OS ではなく BIOS によって) サービスされている間に 0.3 秒間ロックアップするシステムがありました。これを参照してください。そのため、基盤となるハードウェアの機能に注意する必要があります。一般に、最新の PC の管理された冷却をやめることについて心配し始め、常に高速で回転する大きなファンに戻る必要があります。

于 2013-03-21T22:35:40.673 に答える
1

最大の問題は、リアルタイムタスクが最も役立つ多くのシステムには、これらのパッチを機能させるための基本的なハードウェア要件、つまり高解像度タイマー周辺機器がないことです。

私は強く反対します。最大の問題は、警告なしに任意の時間ブロックまたは横取りされる可能性があることです。たまに500ms寝ても、1usの精度で寝られるかどうかはほとんど問題になりません。リアルタイムコンピューティングは、正確な睡眠間隔ではなく、保証された最悪の場合の時間です。I2C EEPROMをプログラムしたい場合は、時間を無駄にすることなく、セットアップ/ホールド時間を可能な限り厳密に満たすことができる高解像度タイマーの恩恵を受けることができます。EEPROMがただそこに座って待機しているので、500msの時折のランダムな遅延は問題ではありません。ただし、これはリアルタイムアプリケーションではありません。サーボを駆動するために1usアップデートで制御ループを実装している場合、その500msの遅延は、システムが制御されていない状態で動作している間、大きな位置の混乱を引き起こします。

ディスクドライバーが割り込みコンテキストでIO完了の処理に数百ミリ秒を費やす可能性があるという事実を回避するために、アプリケーションで何もすることはできません。ドライバーをRTアプリに使いやすくするパッチが、RTカーネルを作成します。

于 2013-03-21T23:38:44.300 に答える