問題タブ [preempt-rt]

Linux、Xenomai、および RTAI の PREEMPT_RT パッチのベンチマークを論文で行うために、ExpressLogic からリアルタイムの Thread_Metric を POSIX に移植しようとしています。これらは、ベンチマークが機能するために実装する必要がある次の関数を含む C ソース ファイルを提供します。

現在、pthread を入力として受け取る tm_thread_suspend および tm_thread_resume 関数を実装しようとしています。pthread_mutex_lock および pthread_cond_wait ルーチンを使用して pthread を一時停止できることは知っていますが、これらはスレッドの start_function から呼び出す必要があります。私はこの種のものに不慣れで、頭を悩ませています。どんな助けでも大歓迎です。

preempt_rt パッチ、Xenomai と RTAI のパフォーマンスを比較する必要があります。それぞれに独自のベンチマークがありますが、同様の結果が得られるわけではなく、すべてのベンチマークが 3 つのプラットフォームすべてで利用できるわけではありません。私が探しているのは、割り込みレイテンシ、コンテキスト切り替え時間などの基本的なパフォーマンスを測定し、3 つのプラットフォームすべてで実行されるベンチマークです。Thread-Metricベンチマークを実装してみましたが、複雑すぎました。そのようなベンチマークが存在するかどうか誰でも知っていますか? 助けてくれてありがとう。

ターゲットハードウェアプラットフォームの馬力が制限されているか、リアルタイムジョブでシステムのオーバーヘッドを最小限に抑える必要があります。これは、通常、デュアルカーネルがネイティブプリエンプションシステムよりも優れている場所です。

ここから：http ：//www.xenomai.org/index.php/Xenomai：Roadmap＃Xenomai_3_FAQ

Preempt_rtは、Linux全体をプリエンプトします。Linuxをプリエンプトすると、どのようにシステムに負荷がかかりますか？

そこでのFAQは、Xenomaiと比較したpreempt_rtについて説明しています。

差出人：https ：//rt.wiki.kernel.org/articles/f/r/e/Frequently_Asked_Questions_7407.html

リアルタイムはカーネルにのみ影響します。ユーザースペースは、より良いリアルタイムの動作を除いて、違いに気づきません。

ユーザースペースでアプリケーションを作成した場合、リアルタイムのハード効果が得られないということですか？

SMP をサポートする VxWorks で実行する優先度の異なる 2 つのタスク「A」と「B」があるとします。'A' と 'B' の両方が I/O デバイス (ディスクや NIC など) にコマンドを発行し、どちらもブロックして結果を待ちます。つまり、「A」と「B」の両方が同時にブロックされます。しばらくして、I/O デバイスが割り込みを発生させ、ISR が呼び出されます。次に、ISR は延期された作業 (別名「下半分」) をワーカー タスクにディスパッチします。質問: ワーカー タスクの優先度は?

VxWorks Device Driver Developer's Guide は少しあいまいです。ワーカータスクの優先度はアプリオリに設定されているようです。結果を待ってブロックされているタスク (「A」と「B」) の優先度に基づいてワーカー タスクの優先度を上げる自動継承メカニズムはありません。これは、PREEMPT_RT Linux でスレッド化された割り込み優先度がどのように機能するかに似ています。ただし、QNX Neutrino と LynxOS の両方が、ブロックされたタスクの最大優先度でワーカー タスクをスケジュールします。優先度(ワーカー) = max_priority(A, B)。

誰でも明確にできますか？

おそらくバージョン 3.3 前後の arago ディストリビューションを使用して、組み込み Linux プロジェクトに取り組んでいます。

ミリ秒ごとにプロセスをウェイクアップする高解像度の Linux タイマーを構成しました。これは問題なく動作しますが、タイミングに関して 2 つの問題があります。

1. 起床時間のジッター
2. プロセスによって実行される処理が一定であるにもかかわらず、起きているときの処理時間の変動性。

これらの問題は、Linux のリアルタイム性に欠けるパフォーマンスに起因すると考えています。しかし、リアルタイムのパフォーマンスを改善する方法を調査する必要があります。

カーネルがリアルタイムに適した CONFIG_PREEMPT カーネル オプションで構成されていることを確認しました。

また、プロセスに SCHED_FIFO スケジューリング クラスを適用しました。

しかし、それは違いはありませんでした。

PREEMPT_RT パッチをカーネル ビルドに適用するのが論理的な手順だと思いますが、その方法はまだ特定できていません。

ジッター/持続時間の変動性を改善するために他にできることはありますか?

または、PREEMPT_RT パッチの適用方法に関するアクセス可能なチュートリアルを提案できる人はいますか?

Xenomai、PREEMPT_RT、および Linux をそのまま Raspberry Pi でベンチマークしようとしていますが、問題が発生しています。

RT優先度と可変スリープ時間で、可変数のスレッドを作成しようとしています。スレッドの 1 つは RT 優先度が高く、GPIO から読み取り、別の GPIO に書き込み (オシロスコープなどでレイテンシを読み取るため)、RT 優先度が低い他のスレッドは算術演算のみを行います。GPIO はメモリにマップされるため、プロトコルのオーバーヘッドを回避できます。

このテストでは次のように考えていました。

問題は、一部のスレッドのみが作成されることです。また、スレッド数が多い場合は、メモリの問題が発生し、プロセスが停止します。それで、私はどのように進めるべきですか？コードが間違っていますか、時間が短すぎますか、それともスレッド数が多すぎますか?

これはコードです：

Linux でタイマーのジッターを特徴付けようとしています。私のタスクは、100 ミリ秒のタイマーを実行し、数値がどのように機能するかを確認することでした。

マルチコアマシンで作業しています。標準のユーザー プログラムを setitimer() で使用し、root と同じように実行し、次にプロセッサ アフィニティを使用し、最後にプロセッサ アフィニティとプロセス優先度を使用しました。次に、PREEMPT_RT カーネルで同じことを実行し、PREEMPT_RT ページのデモ コードのように clock_nanosleep() を使用してサンプルを実行しました。すべての実行の中で、タイマーのパフォーマンスは非常に類似しており、変更にもかかわらず実質的な違いはありませんでした。

私たちの最終目標は安定したタイマーです。私が定期的に得ることができる最高の最悪のケースは約200usでした. すべてのケースのヒストグラムは、非常に奇妙な動作を示しています。1 つには、タイマーが早く起動するとは思わないでしょう。しかし、彼らはそうします。ヒストグラムでわかるように、オフセット 0 の両側に谷があります。これらは、2 番目のグラフの 3 つのバンドに表示されます。最初のグラフでは、X 軸はマイクロ秒単位です。2 番目のグラフでは、Y 軸はマイクロ秒単位です。

30 秒のテスト (つまり、300 個のタイマー イベント) を 100 回実行して、いくつかの数値を生成しました。次の図でそれらを確認できます。200us で大きな低下があります。2 番目のグラフには、30000 個のタイマー イベント クロック オフセットがすべてグラフ化されており、いくつかの異常値を確認できます。

そこで質問なのですが、この種の分析を以前に行った人はいますか? 同じような行動を見たことがありますか？私の推測では、RT カーネルは負荷の高いシステムで役立つと思いますが、私たちの場合、タイマーのジッターを解消するのには役立ちませんでした。それはあなたの経験ですか？

これがコードです。前に言ったように、PREEMPT_RT サイトで clock_nanosleep() 関数を使用するサンプル コードを変更したので、そのための最小限の変更は含めません。

編集: これは Xeon E31220L で、2.2 GHz で実行され、x86_64 Fedora Core 19 が実行されています。

現在、PREEMPT_RT パッチが適用された Linux システム (librt および libpthread を含む) を使用していますが、リアルタイム スレッドはタイミングの観点からかなり信頼できるように動作しているようです。共有リソースへのアクセスに関して、競合状態を防ぐのに適したメカニズムは何ですか? 私の状況では、リアルタイム スレッドと非リアルタイム スレッド (telnet インターフェースなど) の間で統計情報を共有したいと考えています。

例）ミューテックス (''pthread_mutex_lock'' および ''pthread_mutex_unlock'') を使用すると、ミューテックスが非リアルタイム タスクによってロックされ、リアルタイム タスクがそれを待つ。代替手段またはより良いアプローチはありますか?

ビーグルボーン ブラックのカスタム カーネルを構築しています。このガイド ( http://android.serverbox.ch/?p=1273 ) に従って、基本イメージを使用してコンソールを正常に起動できます。

コマンドを使用してリアルタイムカーネルパッチでビルドしようとすると:

次のエラー メッセージが表示されます。

私はREADMEファイルの提案を適用しました（または私がしたと思います...）：

しかし、それでも同じエラー メッセージが表示されます。
Yocto を使用してリアルタイム カーネルの構築に成功した人はいますか? このための決定的な手順はどこにも見つかりません。