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 Next revision Both sides next revision | ||
|
realtime:documentation:howto:tools:cyclictest:start [2018/08/23 14:24] ebugden [Limitations] Improve phrasing |
realtime:documentation:howto:tools:cyclictest:start [2023/08/05 05:18] costa.shul [More Information] + manpage |
||
|---|---|---|---|
| Line 89: | Line 89: | ||
| ===== 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 when the [[realtime:documentation:howto:tools:cyclictest:options:nanosleep|nanosleep]] option is used Cyclictest measuring threads essentially have the shortest possible wake-up time that an RT userspace task can have. When using the nanosleep option, 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. | + | 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. |
| <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 96: | 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]] | ||
| + | |||
realtime/documentation/howto/tools/cyclictest/start.txt ยท Last modified: 2023/08/05 06:45 by costa.shul
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
