For Cyclictest to register a latency, it needs to happen during the intended execution time of a Cyclictest measuring thread. So, if the latency does not happen very often, Cyclictest may need to run for a long time before detecting the latency. If the latency happens at a frequency that is only slightly different from the measuring thread's intended execution frequency, then it could also take a long time to detect. Additionally, if the causes of a latency are partially resolved by the time the measuring thread is supposed to execute, then the full duration of the latency will not be detected. Because of the reasons stated above, it is best to run Cyclictest as long as possible (assuming the other parameters have been chosen appropriately) because running it for a longer time generally means that it has a higher probability of detecting the system's maximum latency.

The default duration of Cyclictest is infinite. If not much is known about a system'm latencies, running the Cyclictest with without a specified duration for a couple of hours is a good place to start.

It is also possible to specify a test duration as a time (–duration) or as a number of iterations (–loops). If Cyclictest is being used as a benchmark, these options are useful for standardizing tests.