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 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.

Using Cyclictest can still be useful in a context like this where the application will experience slightly longer latencies than what Cyclictest measures. This is because the Cyclictest results will be an approximate lower bound for the task's maximum latency. In other words, the maximum latency experienced by the application will not be shorter than what Cyclictest measured. So, if the results that Cyclictest provides are already longer than the application's latency requirements, then the real application's wake-up latency will be even worse. In conclusion, in a situation like this Cyclictest can still be used to get an idea of where improvements are needed.