Real Time Linux Comparison

Author: Emre ERTAŞ, SW Expert – Management Applications Group

Linux was designed to run multiple applications at the same time within different user’s domain. So, we can say that Linux is a multi-process and multi user operating system (OS). It is also called multiprocessor OS in the new decade.

Kernel space was not preemptive before the version 2.6 of Linux kernel while user space was already preemptive. Kernel space could be preempted only by the hardware interrupt service routine (ISR) at the older versions. As a result, any delays and loops would cause scheduling problems.

The real time (RT) phrase is not being as fast as possible but fast as specified. It is basically about guaranteeing latency (a.k.a determinism). RT systems provides you a guarantee that execution will be done within a given time frame. Such systems are expected to provide low latency responses to the external asynchronous events and periodic tasks.

Linux suffers from the lack of real time support. To obtain a timing correctness behavior, it is necessary to make some changes in the kernel sources, i.e. in the interrupt handling and scheduling policies. In this way, you can have a real-time platform, with low latency and high predictability requirements, within full non-real time Linux environment.



Developed by Thomas Gleixner and Ingo Molnár more than a decade ago [1]. PREEMPT.RT reworks the kernel’s “spinlock” locking primitives to maximize the preemptible sections inside the Linux kernel. (PREEMPT.RT was originally called the Sleeping Spinlocks Patch). Basically, it handles asynchronous and synchronous tasks as a sleeping threads, and wake up them by interrupt. This interrupt service routines (ISR) run in kernel threads instead of hard interrupt context. Although it causes extra latency, having priority and interruptible of these tasks make them fully preemptive. Also the tasks have a process ID so they can be observable.

  • The dominant single-kernel solution, widely accepted and has huge community.
  • Based on PREEMPT.RT, almost %80 of the patch is included mainline kernel, it will be fully merged in a couple of years. So, you “won’t need a patch”.
  • Every kernel version has its corresponding patch.
  • Much easier to develop and maintain in contrast to other types of patches.
  • Does not require deep technical knowledge. It is enough to learn POSIX RT API.
  • Has higher latency then dual kernel configuration.


RTAI – the Real-time Application Interface for Linux

RTAI offers traditional services of the Linux kernel core, adding the features of an industrial real-time operating system. It consists of basically an interrupt dispatcher: RTAI mainly traps the peripherals’ interrupts and re-routes them to Linux if necessary.

  • Poor platform support.
  • Requires special API for real time programming.
  • Applicable to limited versions of kernel.
  • Hard to debug, maintain and develop.
  • RTAI is kernel module oriented so it requires experience about loadable kernel modules and decide which part of code is put into userland or kernel space.
  • Has lower latency then its single kernel configuration.
  • Special tools like RTAI-Lab project provides a tool chain to develop block diagrams that can be compiled and executed on the RTAI real-time Linux operating system. RTAI-Lab is included in the RTAI Block diagrams can be developed using either Scilab / Scicos (Open Source) or Matlab / Simulink/RTW (commercial).



Xenomai is another dual kernel model (cobalt core) of real time Linux but it is capable of running single kernel configuration (Mercury core). Micro kernel named Cobalt which is configured to run in dual kernel mode handles interrupts, schedules real-time threads. The Cobalt core has higher priority over the native kernel activities.


  • Wider platform support than RTAI.
  • Requires special API for real time tasks. But it has also emulation APIs such as VxWorks® and pSOS®.
  • Limited versions of kernel patch.
  • Still Hard to debug maintain and develop.
  • Less complicated than RTAI when working in user space.
  • Support both user level programming as well as kernel level. Real time tasks don’t need a kernel module.
  • Has lower latency than the single kernel configuration.
  • Capable of running single kernel configuration with PREEMPT_RT patch. (Mercury core)



Table1 shows some experimental comparisons of time measured with different systems [2]. In the test setup PowerPC based Motorola MVME5500 single-board computer has been tested. The tested program reads 64 channels ADC and produces single output on a DAC. ADC generates an interrupt when a new set of digitized data is ready. Two different test application is considered with little modification. One of the application writes to DAC immediately in ISR (without rescheduling) another one is sets a semaphore, a kernel task which is waiting the semaphore writes to DAC (including rescheduling). An oscilloscope has been used to measure the differences in interrupt latency and rescheduling times between an input signal and the output signal. The study is also considered real time network performances of corresponding system.










2.) Barbalace, A. Luchetta, G. Manduchi,M. Moro, A. Soppelsa, and C. Taliercio. Performance comparison of vxworks, linux, rtai, and xenomai in a hard real-time application. Nuclear Science, IEEE Transactions on, 55(1):435–439, 2008.

Leave a Reply

Your email address will not be published.