The amount of time that Cyclictest should run depends on what it is being used for. When using Cyclictest as a benchmark, the test length can be standardized by specifying a time (–duration) or a number of iterations (–loops).

When using Cyclictest to identify specific latencies (either for the purposes of debugging or performance evaluation), a good place to start is running Cyclictest without a specified duration for a couple of hours. The default duration of Cyclictest is infinite so if no duration is specified the test will run until it is manually stopped.

In general, 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 usually means that it has a higher probability of detecting the system's maximum latency. For Cyclictest to register a latency, the latency 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 these reasons, it is usually best to run the test for as long as is reasonable.