realtime:documentation:howto:debugging:cyclictest:test-design
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:debugging:cyclictest:test-design [2018/07/19 09:54] ebugden Shorten thread real-time priority title for readability |
realtime:documentation:howto:debugging:cyclictest:test-design [2018/07/20 11:04] ebugden Move to Test Design start page |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| Measuring latencies correctly can be complex and time consuming. To make the process less confusing, this page explains some of the concepts to keep in mind when setting up a system for measuring latencies and when selecting Cyclictest options. However, measuring latencies and evaluating a system's performance remains a difficult task that requires an in-depth knowledge of the platform, its intended final purpose (application), and its latency requirements. | Measuring latencies correctly can be complex and time consuming. To make the process less confusing, this page explains some of the concepts to keep in mind when setting up a system for measuring latencies and when selecting Cyclictest options. However, measuring latencies and evaluating a system's performance remains a difficult task that requires an in-depth knowledge of the platform, its intended final purpose (application), and its latency requirements. | ||
| - | |||
| - | ===== Detecting Latencies ===== | ||
| - | |||
| - | Cyclictest measures the difference between the expected execution time of a group of periodic measuring tasks and their actual execution time. So Cyclictest will detect a latency if and only if the latency prevents a measuring task from executing on time. This principle should guide the selection of the Cyclictest options, otherwise relevant latencies could be missed. For example, if the execution period of the measuring task is very long and the latencies always occur and are resolved between the times when the measuring task is supposed to execute, then these latencies will never be noticed by Cyclictest because they never delay the execution of the measuring task. | ||
| ===== System Load ===== | ===== System Load ===== | ||
| Line 17: | Line 13: | ||
| In the end, it can be valuable to run tests using both techniques. If some tests are run using an artificial load and some tests are run using the RT application as the load, then there is a better chance of detecting all the possible latencies that the application could experience. | In the end, it can be valuable to run tests using both techniques. If some tests are run using an artificial load and some tests are run using the RT application as the load, then there is a better chance of detecting all the possible latencies that the application could experience. | ||
| - | ===== Real-Time Priority ===== | + | ===== Option Selection ===== |
| + | |||
| + | Cyclictest measures the difference between the expected execution time of a group of periodic measuring tasks and their actual execution time. So Cyclictest will detect a latency if and only if the latency prevents a measuring task from executing on time. This principle should guide the selection of the Cyclictest options, otherwise relevant latencies could be missed. For example, if the execution period of the measuring task is very long and the latencies always occur and are resolved between the times when the measuring task is supposed to execute, then these latencies will never be noticed by Cyclictest because they never delay the execution of the measuring task. | ||
| + | |||
| + | ==== Thread Wake-up Interval ==== | ||
| + | |||
| + | |||
| + | ==== Real-Time Priority ==== | ||
| + | |||
| + | The priority option (--priority) determines the real-time priority of Cyclictest's latency measuring threads. This option should always be used when running Cyclictest. There are a few things to keep in mind when specifying Cyclictest's priority option. The general idea is that the priority of Cyclictest's measuring threads needs to be lower than what should be measured and higher than what should not be measured. The thread's priority needs to be lower than what should be measured so that the thread will be executed after whatever is producing the latency. In this case the thread's execution will be delayed and the latency will be measured. On the other hand, the thread's priority needs to be higher than what should not be measured so that the thread executes before it and therefore is not delayed by it. | ||
| - | The priority option (--priority) determines the real-time priority of Cyclictest's latency measuring threads. This option should always be used when running Cyclictest. There are a few things to keep in mind when specifying Cyclictest's priority option. | + | <WRAP rightalign>[[realtime:documentation:howto:debugging:cyclictest:test-design:priority|Read more about how to choose thread priority]]</WRAP> |
| - | ===== Test Duration ===== | + | ==== Test Duration ==== |
| For Cyclictest to register a latency, it needs to happen during the intended execution time of a Cyclictest measuring thread. | For Cyclictest to register a latency, it needs to happen during the intended execution time of a Cyclictest measuring thread. | ||
| Line 28: | Line 33: | ||
| When measuring the latencies in a system, it is important to think about interactions and how running Cyclictest could potentially affect the latencies that are being observed. | When measuring the latencies in a system, it is important to think about interactions and how running Cyclictest could potentially affect the latencies that are being observed. | ||
| - | |||
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
