タイマーが早期に起動することを期待しないのは正しいです - そしてそうではありません。 見かけ 早期発火は、前回のタイマーが期限切れになってからの時間を測定していないためです - 前回の gettimeofday() からの時間を測定しています 電話。タイマーが切れてからプロセスが実際にスケジュールされるまでに遅延があった場合、この gettimeofday() が表示されます 遅れて実行され、次は同じ量だけ早く実行されます .
後続の gettimeofday() の違いをログに記録する代わりに 呼び出し、返された絶対時間をログに記録してから、返された時間を最初の時間から N * 100ms と比較してください。
PREEMPT_RT が必要な場合 そのためには、テスト プログラムにリアルタイム スケジューラ ポリシーを設定する必要があります (SCHED_FIFO または SCHED_RR )、ルートが必要です。
私はあなたのコードにいくつかの変更を加え、主に timer を置き換えました 次のように、プロセスを RT の進行状況 (SCHED_FIFO) として実行します。
setitimer() -> timer_create()/timer_settime()
gettimeofday() -> clock_gettime()
私のテストベッドは i9-9900k CPU で、PREEMPT-RT は 5.0.21 カーネルの Linux にパッチを当てています。タイマーの時間間隔は 1 ミリ秒で、プログラムは約 10 時間実行され、次の結果が生成されます。
Cyclictest も実行しています (nanosleep() に基づく) ）、私のマシンで、より優れたレイテンシ制御を示しています（最大レイテンシは15us未満です）.したがって、私の意見では、高解像度のタイマーを自分で実現したい場合は、独立したコアで nanosleep を実行するスタンドアロンの RT スレッドが役立つ場合があります。 RT システムは初めてです。コメントは大歓迎です。