realtime:documentation:howto:tools:cyclictest
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
realtime:documentation:howto:tools:cyclictest [2018/08/21 09:23] ebugden Replace with new cyclictest page tools/cyclictest/start |
— (current) | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Cyclictest ====== | ||
| - | Cyclictest accurately and repeatedly measures the difference between a thread's intended wake-up time and the time at which it actually wakes up in order to provide statistics about the system's latencies. The original test was written by Thomas Gleixner (tglx), but several people have subsequently contributed modifications. Cyclictest is currently maintained by Clark Williams and John Kacur and is part of the test suite [[realtime:documentation:howto:tools:rt-tests|rt-tests]]. | ||
| - | |||
| - | ===== Explanation ===== | ||
| - | |||
| - | 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. | ||
| - | |||
| - | ===== Installation ===== | ||
| - | |||
| - | Installation is explained on [[realtime:documentation:howto:tools:rt-tests#compile-and-install|rt-tests page]]. | ||
| - | |||
| - | ===== Run it ===== | ||
| - | |||
| - | Make sure to be root or use sudo to run cyclictest. | ||
| - | Without parameters cyclictest creates one thread with a 1ms interval timer. | ||
| - | ''cyclictest -h'' provides help text for the various options. | ||
| - | |||
| - | More information is available by running ''man ./src/cyclictest/cyclictest.8''. The [[https://www.osadl.org/Create-a-latency-plot-from-cyclictest-hi.bash-script-for-latency-plot.0.html?&no_cache=1&sword_list[0]=script|OSADL site]] provides a script to plot the latency distribution. | ||
| - | ===== Expected Results ===== | ||
| - | |||
| - | <WRAP center round todo 60%> | ||
| - | TODO: Run all the tests run in Expected results section of https://rt.wiki.kernel.org/index.php/Cyclictest and update here. We need to rerun the tests because they were run in 2006 on a Pentium III system running 2.6.16 kernel. Things have probably changed a bit now. :) | ||
| - | </WRAP> | ||
| - | |||
| - | ===== Application Examples ===== | ||
| - | |||
| - | cyclictest is one of the most frequently used programs for bench-marking realtime systems. It is usually used with some sort of loads. Following are some of the ways cyclictest can be utilized to benchmark a real-time system: | ||
| - | |||
| - | * [[realtime:documentation:howto:tools:rteval|RTEval]] | ||
| - | * [[realtime:documentation:howto:tools:worstcaselatency|Worst Case Latency Test Scenarios]] | ||
| - | |||
| - | |||
| - | ===== FAQ ===== | ||
| - | |||
| - | ==== ps shows the wrong scheduling class SCHED_OTHER ==== | ||
| - | |||
| - | 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. | ||
| - | <code bash> | ||
| - | #>./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 | ||
| - | </code> | ||
| - | |||
| - | ==== chrt shows the wrong scheduling class SCHED_OTHER ==== | ||
| - | |||
| - | 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. | ||
| - | <code bash> | ||
| - | #> chrt -p 4766 | ||
| - | pid 4766's current scheduling policy: SCHED_FIFO | ||
| - | pid 4766's current scheduling priority: 79 | ||
| - | </code> | ||
| - | |||
| - | ==== 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". | ||
| - | <code bash> | ||
| - | #> taskset -c 3 top | ||
| - | #> taskset -p [pid] | ||
| - | </code> | ||
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
