realtime:documentation:howto:tools:cyclictest:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
realtime:documentation:howto:tools:cyclictest:start [2018/08/21 10:58] ebugden [Execution] Update link |
realtime:documentation:howto:tools:cyclictest:start [2023/08/05 06:45] (current) costa.shul [More Information] get_cyclictest_snapshot |
||
|---|---|---|---|
| Line 33: | Line 33: | ||
| </code> | </code> | ||
| - | The options above are not relevant for every situation on every system. The Cyclictest [[realtime:documentation:howto:tools:cyclictest:test-design|Test Design]] page goes into more detail about how to choose the right options for measuring a specific latency on a given system. Additionally, ''cyclictest -h'' provides a quick description of the different program options and more detailed explanations can be found by running ''man ./src/cyclictest/cyclictest.8'' from the root of the [[realtime:documentation:howto:tools:rt-tests|rt-tests]] files. | + | The options above are not relevant for every situation on every system. The Cyclictest [[realtime:documentation:howto:tools:cyclictest:test-design#option-selection|Test Design]] page goes into more detail about how to choose the right options for measuring a specific latency on a given system. Additionally, ''cyclictest -h'' provides a quick description of the different program options and more detailed explanations can be found by running ''man ./src/cyclictest/cyclictest.8'' from the root of the [[realtime:documentation:howto:tools:rt-tests|rt-tests]] files. |
| Running Cyclictest without any options is not recommended as it will not necessarily measure anything useful. Without parameters, Cyclictest creates one thread with an intended wake-up period of 1 ms. | Running Cyclictest without any options is not recommended as it will not necessarily measure anything useful. Without parameters, Cyclictest creates one thread with an intended wake-up period of 1 ms. | ||
| Line 50: | Line 50: | ||
| The table below contains a description of the abbreviated labels in the results: | The table below contains a description of the abbreviated labels in the results: | ||
| - | <WRAP center 400px> | + | <WRAP center> |
| - | ^Abbreviation ^ Label ^ Description | | + | ^ abr. ^ Label ^ Description ^ |
| - | |T | Thread | Thread index and thread ID | | + | | T | Thread | Thread index and thread ID | |
| - | |P | Priority | RT thread priority | | + | | P | Priority | RT thread priority | |
| - | |I | Interval | Intended wake up period for the latency measuring threads (in us) | | + | | I | Interval | Intended wake up period for the latency measuring threads (in us) | |
| - | |C | Count | Number of times the latency was measured i.e. iteration count | | + | | C | Count | Number of times the latency was measured i.e. iteration count | |
| - | |Min | Minimum | Minimum latency that was measured (in us) | | + | | Min | Minimum | Minimum latency that was measured (in us) | |
| - | |Act | Actual | Latency measured during the latest completed iteration (in us) | | + | | Act | Actual | Latency measured during the latest completed iteration (in us) | |
| - | |Max | Maximum | Maximum latency that was measured (in us) | | + | | Max | Maximum | Maximum latency that was measured (in us) | |
| </WRAP> | </WRAP> | ||
| Line 69: | Line 69: | ||
| ===== Analysis ===== | ===== Analysis ===== | ||
| - | The most important value in the results is the maximum detected latency as this value can give an idea of the worst case latency length in the evaluated situation. These results should always be evaluated carefully, as the maximum measured value does not necessarily represent the system's worst case. More details about why the results should be interpreted critically can be found via the Cyclictest [[realtime:documentation:howto:debugging:cyclictest:test-design:start|Test Design]] page and in the Limitations section below. | + | The most important value in the results is the maximum detected latency as this value can give an idea of the worst case latency length in the evaluated situation. These results should always be evaluated carefully, as the maximum measured value does not necessarily represent the system's worst case. More details about why the results should be interpreted critically can be found via the Cyclictest [[realtime:documentation:howto:tools:cyclictest:test-design|Test Design]] page and in the Limitations section below. |
| It is not possible to specify a universally applicable recommended limit for latency length. The Cyclictest results should be analyzed based on the system's timing requirements for the latency of what was being measured. For example, if the latency of a specific real-time task was measured, then the results should be compared with the timing requirements for that specific task. The requirements will determine whether the latencies observed in a system are acceptable or too long. | It is not possible to specify a universally applicable recommended limit for latency length. The Cyclictest results should be analyzed based on the system's timing requirements for the latency of what was being measured. For example, if the latency of a specific real-time task was measured, then the results should be compared with the timing requirements for that specific task. The requirements will determine whether the latencies observed in a system are acceptable or too long. | ||
| Line 85: | Line 85: | ||
| Cyclictest can be used to detect latencies that occur in many different systems and situations. However, a test must be designed carefully because it is relatively easy to not measure the latencies that were intended to be measured. Both the test setup and the parameters passed to Cyclictest need to be carefully chosen as a function of the specific situation in which the latencies are to be evaluated. If these elements are not considered thoughtfully, the Cyclictest results will not accurately represent the latencies that occur in that situation. | Cyclictest can be used to detect latencies that occur in many different systems and situations. However, a test must be designed carefully because it is relatively easy to not measure the latencies that were intended to be measured. Both the test setup and the parameters passed to Cyclictest need to be carefully chosen as a function of the specific situation in which the latencies are to be evaluated. If these elements are not considered thoughtfully, the Cyclictest results will not accurately represent the latencies that occur in that situation. | ||
| - | <WRAP rightalign>[[realtime:documentation:howto:debugging:cyclictest:test-design:start|Read more about how to design a test]]</WRAP> | + | <WRAP rightalign>[[realtime:documentation:howto:tools:cyclictest:test-design|Read more about how to design a test]]</WRAP> |
| ===== Limitations ===== | ===== Limitations ===== | ||
| - | The latencies measured by Cyclictest may be slightly optimistic depending on the final application that will execute on the system. This is because Cyclictest measuring threads essentially have the shortest possible wake-up time that an RT userspace task can have. So, if the application tasks have a slower wake-up time they will experience a longer latency than a Cyclictest measuring thread in an identical situation. | + | The latencies measured by Cyclictest may be slightly optimistic depending on the final application that will execute on the system. This is because [[realtime:documentation:howto:tools:cyclictest:options:nanosleep|nanosleep]] is used by the Cyclictest measuring threads, so they essentially have the shortest possible wake-up time that an RT userspace task can have. When using nanosleep, the Cyclictest thread timer expiry path is executed directly in hard interrupt context with no additional indirection. So, if an application task's wake-up is not completed in hard interrupt context (e.g. threaded interrupt context), the application task will experience a longer wake-up latency than a Cyclictest measuring thread in an identical situation due to the additional level of indirection. In a case like this, the Cyclictest thread's latency measurement will be optimistic even if the latency starts at the exact time that the Cyclictest thread is intended to execute and the thread is affected by the full duration of the latency. |
| - | In a case like this, the Cyclictest thread's measurement will be optimistic even if the latency starts at the exact time that the Cyclictest thread is intended to execute and the thread is affected by the full duration of the latency. | + | |
| <WRAP rightalign>[[realtime:documentation:howto:tools:cyclictest:limitations|Read more about Cyclictest limitations]]</WRAP> | <WRAP rightalign>[[realtime:documentation:howto:tools:cyclictest:limitations|Read more about Cyclictest limitations]]</WRAP> | ||
| Line 97: | Line 96: | ||
| * [[realtime:documentation:howto:tools:cyclictest:faq|Cyclictest FAQ]] | * [[realtime:documentation:howto:tools:cyclictest:faq|Cyclictest FAQ]] | ||
| + | * [[https://man.archlinux.org/man/cyclictest.8.en|cyclictest manpage]] | ||
| + | * [[https://man.archlinux.org/man/get_cyclictest_snapshot.8.en|get_cyclictest_snapshot]] – get a snapshot of running instances of cyclictest | ||
| + | |||
realtime/documentation/howto/tools/cyclictest/start.1534849100.txt.gz · Last modified: 2018/08/21 10:58 by ebugden
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
