This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revision Both sides next revision | ||
realtime:documentation:howto:tools:cyclictest:start [2018/08/23 14:23] ebugden Improve phrasing |
realtime:documentation:howto:tools:cyclictest:start [2018/08/23 14:24] ebugden [Limitations] Improve phrasing |
||
---|---|---|---|
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 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. |
<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> |