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.

To get the most accurate latency measurements, Cyclictest should be executed while the evaluated system is running a load as similar as possible to the final RT application for which the system is intended. During a typical test Cyclictest's overhead is relatively negligible, so it does not really apply a load to the system. In other words, the load must be created in another way. The system load can be created in different ways.

The best way to measure the most realistic latencies that an RT application would experience on a specific system would be to run the actual RT application on the platform along with Cyclictest. However, this method can also have its disadvantages. For example, if the RT application causes system latencies aperiodically at a very low frequency then it could take a very long time for Cyclictest to notice them.

Another solution is to simulate the load generated by the final RT application by using a tool like Hackbench. However, it is possible that an artificial load would not trigger system latencies that would be triggered by the final RT application. If this is the case, the Cyclictest results would not reflect the real maximum latencies.

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.

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.

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.

If latencies caused by the hardware, the firmware, and the OS are being measured, then Cyclictest's priority should be higher than the priority of the application or load that is executing on the platform. If Cyclictest's priority is not higher, then the measured system latency times will be longer than reality because other userspace tasks will be able to execute before the Cyclictest measuring thread has a chance to execute in response to the timer expiry.

If Cyclictest is being used to approximate the latency of RT userspace tasks, then the principles explained in the first paragraph still apply. Cyclictest's priority needs to be lower than the priority of the tasks that are producing the latencies that Cyclictest is supposed to be detecting and higher than the lower priority tasks that are producing latencies that are not to be measured. This will ensure that Cyclictest only measures the latencies experienced by the higher priority tasks whose latencies are supposed to be measured.

Consider the following example. Task A (high priority) and Task B (low priority) are running on a system. If the intention is to measure the influence of Task A on the latencies experienced by Task B, then Cyclictest's priority should be lower than Task A's but higher than Task B's. The Cyclictest measuring threads should have a lower priority than Task A so that they execute after this task and are affected by the additional latency it causes. However, their priority should be lower than Task B's so that they execute before it and are not influenced by Task B.

For Cyclictest to register a latency, it needs to happen during the intended execution time of a Cyclictest measuring thread.

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.