Latency Measurement

There are multiple ways of defining the latency of a given system and equally many ways of measuring it. For this study, a simple and widely used method of evaluating the real-time capabilities of a given system based on scheduling latency was selected. This mimics the behavior of many typical control systems that execute a periodic task that must be precisely timed. Also, this same situation arises when the system is reacting to some external asynchronous events.

The tool in question cyclictest (version 2.20) was used as the main measuring utility in the latency measurements. It was originally built by the authors of PREEMPT_RT to help with the development effort by precisely measuring the system latencies, as presented in Cyclictest Latency Measurement. The cyclictest works by starting a regular master thread, which will start several real-time measuring threads. Each one of these real-time threads is set to periodically wake up after a defined interval. Every time they are woken up, the difference between intended and actual wake-up time is then recorded and passed along to the master process. The master process stores all these results, and once the test ends, it outputs the aggregated results.

Figure 1. Cyclictest Latency Measurement

For SMP systems, such as the VisionFive 2, the cyclictest provides statistics individually for each core. However, having these separated results is not generally important for overall latency evaluation. For this reason, the calculations and graphs presented in this thesis are simplified by simply adding the results from every core together to get a single number of latencies for the whole system. This makes the provided measurement results easier to visualize and understand.

The cyclictest should be carefully configured for each system and measurement scenario.

Most importantly, the priority and interval need to be set according to the measurement situation. To measure system latencies, the priority should be set higher than the load running on the system. The most optimal value for the interval would be slightly bigger than the maximum observed latency. Overall, multiple options were set to specific values to get the most appropriate latency results.

  • --priority=99 selects the measuring thread real-time priority equal to 99.
  • --interval=200 sets the intended measuring thread wake-up period to 200 µs.
  • --duration=10m sets the total duration of the measurement to 10 minutes.
  • --histogram=200 enables histogram generation from the measurement up to latencies of 200 µs.
  • --smp causes a single pinned thread to be launched for each available core.
  • --mlockall makes process memory lock paging once everything is allocated.

The cyclictest tool also automatically sets some noteworthy parameters, which could also be manually set, to default values based on these selections. Most notably the distance parameter of measurement thread intervals is automatically set to zero because the histogram option is specified. In addition, the scheduling policy is by default set to SCHED_FIFO. Altogether, these parameters are quite typical and well-suited for measuring latencies that a real-time application would experience.