Cyclictest is a high resolution test program originally written by Thomas Gleixner (tglx). A lot of people contributed to it later on and it is currently being maintained by Clark Williams and John Kacur. It is part of the test suite rt-tests.

cyclictest runs a non real-time master thread which starts a defined number of measuring threads with a defined real-time priority. The measuring threads are woken up periodically with a defined interval by an expiring timer (cyclic alarm). Subsequently, the difference between the programmed and the effective wake-up time is calculated and handed over to the master thread via shared memory. The master thread tracks the latency values and prints the minimum, maximum and average for the latency once the number of iterations specified is completed.

Installation is explained on rt-tests page.

Make sure to be root or use sudo to run cyclictest. Without parameters cyclictest creates one thread with a 1ms interval timer. cyclictest -h provides help text for the various options.

More information is available by running man ./src/cyclictest/cyclictest.8. The OSADL site provides a script to plot the latency distribution.

cyclictest is one of the most frequently used programs for bench-marking realtime systems. It is usually used with some sort of loads. Following are some of the ways cyclictest can be utilized to benchmark a real-time system:

• RTEval
• Worst Case Latency Test Scenarios

Each cyclictest-task consist of one or more threads. ps -ce shows only the main-process not the threads of the main-process. ps -eLc | grep cyclic shows the main-process an the containing threads with the correct scheduler class SCHED_FIFO.

#>./cyclictest -t5 -p 80 -n -i 10000
 
#> ps -cLe | grep cyclic
 4764  4764 TS   19 pts/1    00:00:01 cyclictest
 4764  4765 FF  120 pts/1    00:00:00 cyclictest
 4764  4766 FF  119 pts/1    00:00:00 cyclictest
 4764  4767 FF  118 pts/1    00:00:00 cyclictest
 4764  4768 FF  117 pts/1    00:00:00 cyclictest
 4764  4769 FF  116 pts/1    00:00:00 cyclictest

Don't use the PID of the main-process, but the pid of one of the threads from the main-process. The threads are shown with ps -cLe | grep cyclic.

#> chrt -p 4766
pid 4766's current scheduling policy: SCHED_FIFO
pid 4766's current scheduling priority: 79

taskset command is Written by Robert M. Love. SMP operating systems have choices when it comes to scheduling processes: a new or newly rescheduled process can run on any available cpu. However, while it shouldn't matter where a new process runs, an existing process should go back to the same cpu it was running on simply because the cpu may still be caching data that belongs to that process. This is particularly apt to be true if the process is a thread: the other threads in the same program are very likely to have cpu cache of interest to their brethren (though obviously this also diminishes the performance gain that might be seen from multithreading) . For these reasons, scheduling algorithms pay attention to cpu affinity and try to keep it constant. It is possible to force a process to run only on a certain cpu. There are Linux system calls (sched_setaffinity and sched_getaffinity) and a command line “taskset”.

#> taskset -c 3 top
#> taskset -p [pid]