Here are answers to 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 latencies after each iteration (default) or once the number of iterations specified is completed (–quiet).

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 -t 5 -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

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 --pid 4766
pid 4766's current scheduling policy: SCHED_FIFO
pid 4766's current scheduling priority: 79

When measuring the latencies on a subset of the CPUs, make sure that the main Cyclictest thread is running on the CPUs that are not being evaluated. For example, if a system has two CPUs and the latencies on CPU 0 are being evaluated, then the main Cyclictest thread should be pinned to CPU 1. Cyclictest's main thread is not real-time, but it can potentially have an affect on the latencies if it executes on the evaluated CPU(s) because there will be additional context switches. The main thread can be restricted to execution on a certain subset of CPUs using the --mainaffinity=CPUSET option. For example, the main thread can be pinned to CPU 1 using --mainaffinity=1.

The taskset command can be used to make sure that other programs running on the system do not affect the latencies on the isolated CPU(s). For example, the program top can be started and pinned to CPU 1 using this command:

# taskset --cpu 1 top