====== 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 latencies after each iteration (default) or once the number of iterations specified is completed (--quiet).
==== 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 -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
==== 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 --pid 4766
pid 4766's current scheduling policy: SCHED_FIFO
pid 4766's current scheduling priority: 79
==== How can the influence of Cyclictest be minimized when evaluating latencies on an isolated set of CPUs? ====
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 [[realtime:documentation:howto:tools:cpu-partitioning:taskset|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