This is an old revision of the document!
Here are a few frequently asked questions about Cyclictest.
To measure latencies, Cyclictest runs a non real-time master thread (scheduling class SCHED_OTHER) which starts a defined number of measuring threads with a defined real-time priority (scheduling class SCHED_FIFO). 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.
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]