一、テストコマンド./cyclictest –p 80 –t5 –n
1.デフォルトで5個のSCHED_を作成FIFOポリシーのrealtimeスレッド、優先度80、実行周期は1000150020025003000マイクロ秒、干渉のないテスト結果図:
このことから、AdvLinux 3.0.2リアルタイムシステムでは、最小値は2~3マイクロ秒、平均値は9~11マイクロ秒であり、最大値は24~29マイクロ秒の間に分布する.
2.同じテストを実行するが、このテストを実行する過程でより多くの干渉を導入し、デバイスを他のデバイスとシリアル通信すると、結果は干渉テスト結果図になる.
最大値34 usのシリアル通信プロセスを導入した.AdvLinux 3は表示されません.0.2非リアルタイムシステムでは、最大値は1219マイクロ秒であった.     
二、テストコマンド./cyclictest--smp -p95 -m
この結果は、Cyclictestツールがクアッドコアシステムで実行され、すべてのメモリがロックされている場合、各カーネルが測定スレッドを実行し、各SCHED_FIFOの優先順位は95で、メモリ割り当てをロックします.試験の結果、CPU 0の最大遅延は33 us、平均遅延は9 usであった.CPU 1の最大遅延は33 usであり、平均遅延は9 usである.CPU 2の最大遅延は32 us、平均遅延は12 usである.CPU 3の最大遅延は29 us、平均遅延は13 usである.
cat/proc/cpuinfoビューシステムはコアシステムです
三、テストコマンド./cyclictest -t1 -p 80 -n -i number  -l10000
図1
スレッド優先度は80であり、異なる時間間隔での結果であり、C:9397カウンタである.スレッドの間隔が1回に達するごとにカウンタに1を加算
Min:最小遅延(us);Act:最近の遅延(us);Avg:平均遅延(us);Max:最大遅延(us)
Iが500 usの場合,最小遅延は2,平均は11,最大は26であった.Iが10000 usの場合,最小遅延は4,平均は17,最大は33であった.

RT-Pleempt Patchイネーブル

RT-Pleempt PatchのLinux kernelに対する主な改造は以下の通りである.

Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes:

Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t)

Implementing priority inheritance for in-kernel spinlocks and semaphores. For more information on priority inversion and priority inheritance please consultIntroduction to Priority Inversion

Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common userspace process. However it is also possible to register an IRQ in kernel context.

Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to userspace POSIX timers with high resolution.

1. What is "latency"?
------------------------------------------------------------------------------

The term latency, when used in the context of the RT Kernel, is the
time interval between the occurance of an event and the time when that
event is "handled" (typically "handled" means running some thread as a
result of the event). Latencys that are of interest to kernel
programmers (and application programmers) are: 

    - the time between when an interrupt occurs and the thread
      waiting for that interrupt is run

    - the time between a timer expiration and the thread waiting for
      that timer to run

    - The time between the receipt of a network packet and when the
      thread waiting for that packet runs

Yes, the timer and network example above are usually examples of the
more general interrupt case (most timers signal expiration with an
interrupt and most network interface cards signal packet arrival with
an interrupt as well), but the main idea is that an "event" occurs and
there is some elapsed time interval which concludes with the kernel
successfully handling the event.

So, latency in and of itself is not a bad thing; there is always a
delay between occurance and completion of an event. What is bad is
when latency becomes excessive, meaning that the delay exceeds some
arbitrary threshold. What is this threshold? That's for each
application to define. A threshold or "deadline" is what defines a
real time application: meeting deadlines means success, missing
deadlines (exceeding the threshold) means failing to be real time. 

https://rt.wiki.kernel.org/index.php/Cyclictest