{"id":7815,"date":"2025-11-29T06:42:46","date_gmt":"2025-11-29T05:42:46","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7815"},"modified":"2026-02-13T14:58:21","modified_gmt":"2026-02-13T13:58:21","slug":"how-to-measure-rtos-performance","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/how-to-measure-rtos-performance\/","title":{"rendered":"How to Measure RTOS Performance"},"content":{"rendered":"

And how to read data sheets<\/h2>\n

Author: Colin Walls, Mentor Graphics<\/p>\n

Beitrag – Embedded Software Engineering Kongress 2017<\/h3>\n

Why Make Measurements?<\/h2>\n

Desktop or laptop computers are extremely powerful and amazingly low cost. This means that developers of software for desktop systems assume that there is infinite CPU power, so they worry very little about the speed of their code. They also assume that indefinite amounts of memory are available, so they do not worry about code size either.<\/p>\n

Embedded systems are different. Typically, there is enough CPU power to do the job, but only\u00a0just<\/em>\u00a0enough \u2013 there is no excess. Memory size is limited. It is not normally unreasonably small, but there is unlikely to be any possibility of adding more. Power consumption is usually an issue and the software \u2013 its size and efficiency \u2013 can have a significant bearing on the number of Watts burned by the embedded device. It is clear that, with an embedded system, it is vital that the RTOS has the smallest possible impact on memory footprint and makes very efficient use of the CPU.<\/p>\n

RTOS Metrics<\/h2>\n

There are three areas of interest if you are looking at the performance and usage characteristics of an RTOS:<\/p>\n

    \n
  1. Memory \u2013 how much ROM and RAM does the kernel need and how is this affected by options and configuration.<\/li>\n
  2. Latency, which is broadly the delay between something happening and the response to that occurrence. This is a particular minefield of terminology and misinformation, but there are two essential latencies to consider: interrupt response and task scheduling.<\/li>\n
  3. Performance of kernel services. How long does it take to perform specific actions?<\/li>\n<\/ol>\n

    Each of these measurements will be addressed in turn.<\/p>\n

    A key problem is that there is no real standardization. One possibility would be the Embedded Microprocessor Benchmark Consortium, but that is not widely adopted and, anyway, it is more oriented towards CPU benchmarking<\/p>\n

    RTOS Metrics – Memory Footprint<\/h2>\n

    As all embedded systems have some limitations on available memory, the requirements of an RTOS, on a given CPU, need to be understood. An OS will use both ROM and RAM.<\/p>\n

    ROM, which is normally flash memory, is used to store the kernel code, along with the code for the runtime library and any middleware components. This code \u2013 or parts of it \u2013 may be copied to RAM on boot up, as this can offer improved performance. There is also likely to be some read only data. If the kernel is statically configured, this data will include extensive information about kernel objects. However, nowadays, most kernels are dynamically configured.<\/p>\n

    RAM space will be used for kernel data structures, including some or all of the kernel object information, again depending upon whether the kernel is statically or dynamically configured. There will also be some global variables.
    \nIf code is copied from flash to RAM, that space must also be accounted for.<\/p>\n

    Dependencies:<\/strong><\/p>\n

    The CPU architecture is key. The number of instructions can vary drastically from one processor to another, so looking at size figures for one specific CPU gives no indication of what the size might be like for a different CPU or even another device in the same family.<\/p>\n

    Embedded compilers generally have a large number of optimization settings. These can be used to reduce code size, but that will most likely affect performance. Optimizations affect ROM footprint, but also RAM if the code is copied. Data size can also be affected by optimization, as data structures can be packed or unpacked. Again both ROM and RAM can be affected. Packing data has an adverse effect on performance.<\/p>\n

    Most RTOS products have a number of optional components. Obviously, the choice of those components will have a very significant effect upon memory footprint.
    \nMost RTOS kernels are scalable, which means that, all being well, only the code to support required functionality is included in the memory image. For some RTOSes, scalability only applies to the kernel. For others, scalability is extended to the rest of the middleware.<\/p>\n

    Different people have different ideas about what scalability means. Fine grain scalability means that only the core of the RTOS [the scheduler etc.] and the code for the service calls that are actually used are included in the final memory image. There should be no redundant code.<\/p>\n

    Measurement:<\/strong><\/p>\n

    Although an RTOS vendor may provide or publish memory usage information, you may wish to make measurements yourself in order to ensure that they are representative of the type of application that you are designing.<\/p>\n

    These measurements are not difficult. Normally the map file, generated by the linker, gives the necessary memory utilization data. Different linkers produce different kinds of map files with varying amounts of information included in a variety of formats. Possibilities extend from a mass of hex numbers through to an interactive HTML document and everything in between.
    \nThere are some specialized tools that extract memory usage information from executable files. An example is\u00a0objdump<\/em>.<\/p>\n

    Importance:<\/strong><\/p>\n

    The importance of RTOS memory footprint must be understood, as its implications may be non-obvious.<\/p>\n

    As mentioned earlier, memory is always an issue with embedded systems, but the detailed priorities vary from one system to another.
    \nA small system may only have limited on-chip memory and, of course, the application code must be accommodated. Hence, the RTOS must be as small as possible.<\/p>\n

    A bigger system may not have such a pressure on total memory space. System performance is more likely to be the priority. This means that the peak performance is required from the RTOS, so placing it into on-chip memory or locking it into cache may be attractive. Both of these options are most feasible if the kernel size is minimized.
    \nIf the system copies code from flash to RAM, it is particularly important to understand the memory space requirements.<\/p>\n

    RTOS Metrics – Interrupt Latency<\/h2>\n

    The time related performance measurements are probably of most concern to developers using an RTOS.<\/p>\n

    A key characteristic of a real time system is its timely response to external events. An embedded system is typically notified of an event by means of an interrupt, so the delay between the interrupt occurring and the response to that interrupt \u2013 the interrupt latency \u2013 is critical.
    \nUnfortunately, there are two definitions, at least, of the term \u201cinterrupt latency\u201d:<\/p>\n

    System<\/strong>: the total delay between the interrupt signal being asserted and the start of the interrupt service routine execution.<\/p>\n

    OS<\/strong>: the time between the CPU interrupt sequence starting and the initiation of the ISR. This is really the operating system overhead, but many people refer to it as the latency. This means that some vendors claim zero interrupt latency<\/p>\n

    The two definitions are illustrated in this diagram (see\u00a0PDF\u00a0<\/a>file).<\/p>\n

    Measurement:<\/strong><\/p>\n

    Interrupt response is the sum of two distinct times:\u00a0\u01aeIL<\/sub>\u00a0=\u00a0<\/strong>\u01aeH<\/sub>\u00a0+\u00a0<\/strong>\u01aeOS<\/sub><\/strong><\/p>\n

    where:<\/p>\n

    \u01aeH<\/sub><\/strong>\u00a0is the hardware dependent time, which depends on the interrupt controller on the board as well as the type of the interrupt<\/p>\n

    \u01aeOS<\/sub><\/strong>\u00a0is the OS induced overhead<\/p>\n

    Ideally, quoted figures should include the best and worst case scenarios. The worst case is when the kernel disables interrupts.<\/p>\n

    To measure a time interval, like interrupt latency, with any accuracy, requires a suitable instrument. The best tool to use is an oscilloscope. One approach is to use one pin on a GPIO interface to generate the interrupt. This pin can be monitored on the \u2018scope. At the start of the interrupt service routine, another pin, which is also being monitored, is toggled. The interval between the two signals may be easily read from the instrument.<\/p>\n

    Importance:<\/strong><\/p>\n

    Many embedded systems are real time and it is those applications, along with fault tolerant systems, where knowledge of interrupt latency is important.<\/p>\n

    If the requirement is to maximize bandwidth on a particular interface, the latency on that specific interrupt needs to be measured. To give an idea of numbers, the majority of systems exhibit no problems, even if they are subjected to interrupt latencies of tens of microseconds<\/p>\n

    RTOS Metrics – Scheduling Latency<\/h2>\n

    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.<\/p>\n

    There are really two separate measurements to consider:<\/p>\n