How to Measure RTOS Performance

Seite: 4/4

Firma zum Thema

RTOS Metrics – Scheduling Latency

A key part of the functionality of an RTOS is its ability to support a multi-threading execution environment. Being real time, the efficiency at which threads or tasks are scheduled is of some importance.

The scheduler is at the core of an RTOS, so it is reasonable that a user might be interested in its performance.


It is hard to get a clear picture, as there is a wide variation in the techniques employed to make measurements and in the interpretation of the results.

There are really two separate measurements to consider:

  • the context switch time
  • the time overhead that the RTOS introduces when scheduling a task

The context switch latency is the time it takes for the context switch to complete.

In diagram 2 we are looking at the elapsed time between the last instruction from Task A being executed and the first instruction from Task B.

It is unlikely to make any difference whether Task B has been run before and was paused or it is being run for the first time.

The other scenario is when the RTOS is idling and an external event causes the RTOS to schedule a task. In this case, the overhead is the elapsed time before the required task is actually running, as shown in diagram 3.


The scheduling latency is the maximum of two times:



ƮSO is the scheduling overhead; the end of the ISR to the start of task schedule

ƮCS is the time taken to save and restore thread context

Measurements may be made in a similar way to the interrupt latency timings.

Measurements may be made in a similar way to the interrupt latency timings.


Developers who are working on time critical or fault tolerant systems are likely to be interested in scheduling latency. Much the same as interrupt latency, but remember they are quite different measurements and must both be considered individually.

RTOS Metrics – Timing Kernel Services

An RTOS is likely to have a great many API calls, probably numbering into the hundreds. To assess timing, it is not useful to try to analyze every single call. It makes more sense to focus solely on the frequently used services.

For most RTOSes, there are four key categories of service call:

  • Threading services
  • Synchronization services
  • Inter-process communication services
  • Memory services


All RTOS vendors provide performance data for their products, some of which is more comprehensive than others. This information may be very useful, but can also be misleading if interpreted incorrectly.

It is important to understand the techniques used to make measurements and the terminology used to describe the results. There are also trade-offs – generally size against speed – and these, too, need to be thoroughly understood. Without this understanding, a fair comparison is not possible.

If timing is critical to your application, it is strongly recommend that you perform your own measurements. This enables you to be sure that the hardware and software environment is correct and that the figures are directly relevant to your application.

* Colin Walls has over thirty years experience in the electronics industry, largely involved with embedded software - very much a pioneer in this specialty. He is an embedded software technologist with Mentor Embedded and maintains a blog at