Cyclictest is not intended for measuring the latencies of applications running on real-time systems. However, in some cases it can be used to get a rough estimate of an RT application's response time or a userspace RT task's response time.

Before measuring any latencies, the platform should be running all RT and non-RT applications that would normally be executing. The system should be in a situation that is as close as possible to its final setup in terms of CPU use, memory use, network use, etc. This is done so that the latencies on the system will be influenced by everything that would influence them in the final production setup. This system load will produce the most realistic latencies.

Approximating application latencies requires two different runs of Cyclictest, one to establish a baseline performance and a second to determine how the baseline changes with the influence of the application or task. After these two tests have been completed, the approximate maximum latency of the application or task can then be determined by calculating the difference between these two results. The baseline is determined by running Cyclictest with a priority that is higher than the task or application whose performance is to be measured. The value influenced by the application or task is measured by giving Cyclictest a priority that is slightly lower than the evaluated application or task.

Application latency approximation using Cyclictest is similar to measuring system latencies. Most of the principles explained on the Cyclictest test design page about choosing program options still apply here and these pages can be read to help determine which options are appropriate for the test situation.

Because there are so many factors involved in generating the latencies, it is particularly important to run the tests as long as possible when approximating application performance.

When approximating the performance of all the RT tasks on a system, the baseline is the system latency caused by the OS and everything below the OS. This baseline latency can be evaluated by running Cyclictest with a priority that is higher than the highest priority task in the RT application. For the second run, assign Cyclictest a priority that is lower than the lowest priority task in the RT application. The application's maximum latency can be approximated by subtracting the first test's maximum measured latency from the second test's.

When approximating the latency of a specific RT task, the baseline is determined by running Cyclictest with a priority that is just higher than the evaluated task. The second run is performed with a priority that is just lower than the evaluated task. After these two runs, the performance of the application can be approximated by subtracting the baseline's maximum latency from the second run's maximum latency.

This technique can only be used to approximate the response time of an RT task if there are no other tasks in the RT application that have the same priority as the evaluated task. Additionally, during each run Cyclictest must have a priority that is unique among the other RT tasks. These two criteria are necessary for minimizing the influence of other tasks on the latency results.