6.4.0私はLinuxカーネルとパッチを使ってLinuxリアルタイムシステムをカスタマイズしていますpatch-6.4.6-rt8。実行時にmake menuconfigリアルタイムのパフォーマンスを向上させるには、どの設定をオフにする必要がありますか？システムは主にロボットアームコントローラーとして機能します。
この時点でシステムを使用してcyclictest遅延効果をテストしたところ、ジッタが最小値2、最大値39でやや高いことがわかりました。
# cyclictest -t1 -p 80 -n -i 1000 -l 10000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.27 0.07 0.02 1/122 627
T: 0 ( 577) P:80 I:1000 C: 10000 Min: 2 Act: 2 Avg: 2 Max: 39
#
ベストアンサー1
一般的に言えばそうではありません。システムのリアルタイム特性は、システムの機能ではなく、-rt パッチセットを適用するかどうか、適切なリアルタイム操作が必要なソフトウェアを設計して実行するかどうかによって決まります。遅延時間を追加するrtパッチカーネルで唯一のことは、割り込みが無効になっている長い重要なセクションを持つドライバです。ただし、ほとんどのデバイスでは、おそらくカーネルドライバが実行されているときは機能しません。ドライバをアンインストールすると無効になります。使用しているハードウェアコンポーネント。だから私はそれがオプションだとは思わない。
ハンドルが「ABeginner」なので、最初から独自のカーネル構成を構築するのではなく、oldconfigLinuxディストリビューションで-rtカーネルを使用するか、提供する場合は-rtカーネルを使用してください。あなたのディストリビューションが付属しています。
この時点で、シクロテストを使用して遅延効果をテストしたところ、ジッタは最小値2、最大値39でわずかに高いことがわかりました。
最新のx86_64またはaarch64システムの範囲内では、この数字は良く見えます。あなたは「ジッタが少し高い」と言いましたが、リアルタイム信号処理に関わるエンジニアとして「やや高い」というのは実際には問題になりません。最大遅延は動作または動作しません。これがリアルタイムシステムの中核です。
したがって、39 µsが十分であると結論付けるか（実際にはおそらくそうです！たとえば、オーディオ関連の項目の場合や機械の緊急停止コントローラの場合は十分ではないかもしれません）、そうでないと結論付けます。しかし、その理由は何であるか尋ねます。精度テストを実行したい場合nanosleep（カーネル空間でハードウェアタイマー割り込みを処理する代わりに）、これは実際にもう少し進むと思います。ライブアプリケーションプロセスにどのコアを固定するかを把握することが含まれます（そのようなプロセスがある場合は、再びuserlandを測定しているので、nanosleepaが必要です）。これは、イベントソースとイベントソース（単純なタイマー以上であると仮定）とイベントで動作するシステムの間のチェーンにあることに関連しています。したがって、残念ながら、リアルタイムシステムの改善のすべての問題は、FreeRTOSなどの単純なオペレーティングシステムと同様に、Linuxにも当てはまります。