This is an old revision of the document!
Table of Contents
Cyclictest - FAQ
Here are answers to a few frequently asked questions about Cyclictest.
How does Cyclictest measure latencies?
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.
Why does ps show Cyclictest as begin scheduled under a normal policy (SCHED_OTHER) not a real-time policy?
The Cyclictest task always has one or more threads, several measuring threads which are scheduled under a real-time policy and a main thread (used to aggregate the measurements) which is scheduled under a normal policy. The command ps -ce only shows the main process and not its measuring threads. To also see the measuring threads, use the command ps -eLc | grep cyclic which shows the main-process and all its threads which are indicated as being scheduled under a real-time policy (SCHED_FIFO). An example of output from the correct command is below. The first column is PID (process ID), the second column is LWP (light weight process ID, thread ID), the third column is CLS (scheduling class, scheduling policy), and the fourth column is PRI (priority).
# ./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
Why does chrt show Cyclictest as begin scheduled under a normal policy (SCHED_OTHER) not a real-time policy?
The Cyclictest task consists of one or more threads, a main thread which is scheduled under SCHED_OTHER and measuring threads which are scheduled under a read-time policy (SCHED_FIFO). So, if the main thread PID is passed to chrt, then the indicated scheduling policy will be SCHED_OTHER. To see information about a measuring thread, its own PID must be passed to chrt. In Linux, threads are implemented as light weight processes so the measuring threads have a PID. These PIDs can be found using ps -cLe | grep cyclic whose output is explained in the answer to the previous FAQ question. Additionally, the example below uses the output in the example from the previous question.
# chrt -p 4766 pid 4766's current scheduling policy: SCHED_FIFO pid 4766's current scheduling priority: 79
taskset for CPU affinity
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]
