Differences

This shows you the differences between two versions of the page.

--- realtime:documentation:howto:debugging:cyclictest:faq [2018/07/24 09:29]
ebugden [How can the influence of Cyclictest be minimized when evaluating latencies on an isolated set of CPUs?] Correct typos, improve phrasing
+++ — (current)
@@ Line 1: / Line 1: @@
-====== 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).
-<code bash>
-# ./cyclictest -t 5 -p 80 -n -i 10000
-# ps -cLe | grep cyclic
-  4764 TS   19 pts/1    00:00:01 cyclictest
-  4765 FF  120 pts/1    00:00:00 cyclictest
-  4766 FF  119 pts/1    00:00:00 cyclictest
-  4767 FF  118 pts/1    00:00:00 cyclictest
-  4768 FF  117 pts/1    00:00:00 cyclictest
-  4769 FF  116 pts/1    00:00:00 cyclictest
-</code>
-==== 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.
-<code>
-# chrt --pid 4766
-pid 4766's current scheduling policy: SCHED_FIFO
-pid 4766's current scheduling priority: 79
-</code>
-==== 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 and it can potentially have an affect on the latencies that are measured if it executes on the evaluated CPUs. After starting Cyclictest, the main thread can be restricted to execution on a certain subset of CPUs using the [[realtime:documentation:howto:tools:cpu-partitioning:taskset|taskset]] command. For example, if the main thread's PID is 4764, then it can be pinned to CPU 1 using the following command:
-<code bash>
-# taskset -cp 1 4764
-</code>
-The //taskset// program can also 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:
-<code bash>
-# taskset --cpu 1 top
-</code>

Wiki

User Tools

Site Tools

Differences

Page Tools