The interval option (–interval) determines the intended execution period of Cyclictest's latency measuring threads.

Ideally the timer interval should be slightly longer than the longest observable latency. If the timer interval is shorter than the longest observable delay then the execution of a measuring thread could potentially be delayed for longer than an entire timing period. This will not necessarily have a negative effect on the system, but conceptually it does not make sense. On the other hand, if the timer is much longer than the longest observable latency then the chances of actually observing the latency will be low because the latency would be short enough to frequently occur and be resolved between two latency measurements.

However, if the approximate length of the maximum latency is not known, initially a very small interval (as small as 50-100 us) can be chosen. When using a smaller interval, Cyclictest will have a higher impact on the system because of the more frequent measurements, but there will be a higher chance of observing a latency. This allows the observer to more quickly get an idea of the order of magnitude of the system's maximum latency. Once the approximate length of the maximum latency is known then the interval can be extended to longer than this latency.

Cyclictest uses high-resolution timers so it is possible to specify wake-up intervals that are shorter than a jiffy.

If there are multiple measuring threads, the distance option (–distance) can be used to specify a difference between each thread's wake-up period. This option should always be specified if there is more than one thread. For most test situations, the measuring threads should all have the same interval (–distance=0).