Rapid Reaction Linux:

Linux with low latency and high timing accuracy

combining the 'Low Latency Patch'with the 'UTIME Patch', adding some ideas

Rapid Reaction Linux is now also available for Linux 2.4.18, please contact arnd.heursch@unibw-muenchen.de

Rapid Reaction Linux is now available as a kernel patch for the Linux kernel 2.4.0-test6 on intel compatible x86 systems from Pentium and above

Because I did not find a hint, that Ingo Molnar's Patch is GPL'ed,
so you have to download and apply 2 patches to get a Rapid Reaction Linux:

You need a fresh copy of the Linux 2.4.0-test6 kernel and these two patches :

  1. lowlatency-2.4.0-test6-C4 von der Seite http://people.redhat.com/mingo/lowlatency-patches/lowlatency-2.4.0-test6-C4

  2. Rapid Reaction Kernel Patch for Linux 2.4.0-test6 with Low Latency C4 Patch from this site. This is code is in beta state.


Apply the patches from the top-level of a clean 2.4.0-test6 kernel with the following commands (assuming the patch is in /tmp):

    1. patch -p1 -b </tmp/lowlatency-2.4.0-test6-C4

    2. patch -p1 -b < /tmp/rap_reac.patch


      Don't change the order of the patches to apply.

0. Copyright and Credits

The Rapid Reaction Kernel Patch has been written in 2001 at the Department of Computer Science, University of Federal Armed Forces, Munich

This software may be used and distributed according to the terms of the GNU Public License, incorporated herein by reference. We donīt accept any liability whatsoever for this product.

This patch uses mainly code of the UTIME Patch, created at The University of Kansas, - developed for the Linux Kernel 2.2.13 published under GPL, and it needs the code of Ingo Molnarīs famous 'Low Latency Patch', too, which seems not to be GPL'ed ???

The restricitions applying for the UTIME patch also apply to Rapid Reaction Linux,
please read therefore the site: UTIME Patch

Please send bug-reports/suggestions/comments to arnd.heursch@unibw-muenchen.de



I. Introduction

We published a paper about Rapid Reaction Linux. It has been published first at the 5th Annual Linux Showcase & Conference, Oakland, California, USA, November 8-11, 2001

Rapid Reaction Linux has been created at the University of German Federal Armed Forces in order to enhance realtime capabilities of the standard Linux kernel.

Rapid Reaction Linux combines two well known patches to achieve this goal on the Intel x86 architecture using processors like Intel Pentium or any newer descendant.



Rapid Reaction Linux combines the LOW LATENCY Patch, provided by Ingo Molnar, which has been found to reduce long latencies in the Linux kernel, with the UTIME Patch of Kansas University that improves the precision of standard Linux timing services. Rapid Reaction Linux is not related to the well known KURT Linux, except for the UTIME patch, both systems are relying on.

Our measurements and the measurements of many others show that the ``Low Latency Patch'' can reduce many long latencies from the order of 100 ms to the order of 5 to 10 ms.

Having a Linux kernel with reduced latencies it is even more interesting to have also an accurate time basis. Therefore we ported the UTIME Patch from Linux 2.2 to Linux 2.4 and combined it with Ingo Molnarīs ``Low Latency Patch''.

We improved the accuracy of the UTIME timers and introduced ``soft realtime timers''. The resulting Linux kernel patch we called Rapid Reaction Linux.

In our measurements it shows a very good timing accuracy when executing periodical tasks.

Standard Linux shows a standard lag of 10 ms for periodical tasks, Rapid Reaction Linux does not. In standard Linux the first period of the task is often shorter than the following periods, in Rapid Reaction Linux the first period has the correct length like all the following periods.
Standard Linux can't schedule periods in between 2 and 20 ms, Rapid Reaction Linux can.

Standard Linux schedules tasks with periods which are not a multiple of 10 ms, - the period of the timer interrupt -, with a delay in between 10 and 20 ms - not including possible latencies - to round up their period to a 10 ms boundary. Rapid Reaction Linux can schedule these periods - without rounding their period - , with a mean delay on the order of tens of microseconds. So Rapid Reaction Linux is best suited for periodical tasks and/or for waiting only once an desired amount of time.

A guarantee about the value of the longest latency in the Linux kernel - with or without the kernel patch of Rapid Reaction Linux - can't be given at the present stage of development - in our opinion -, because nobody can test all paths of the Linux kernel code and their mutual interferences.

Concerning the latencies the ``Low Latency Patch'' incorporated in Rapid Reaction Linux reduces many long latencies from the order of 100 ms to the order of 5 ms to 10 ms on current hardware.

So the higher timing accuracy is disturbed much less by latencies induced by Linux system calls or kernel threads. This is an important reason for the higher timing accuracy to make sense.

We will continue to develop Rapid Reaction Linux to better the services it can provide for time-critical tasks.



II. Usage

To use the UTIME system, patch the kernel with the two patches (Use patch -p1 -b < patch_file_name). Then configure the kernel and enable CONFIG_UTIME ('Microsecond Resoulution Timer Support'). This option is located in the "Kernel Hacking" submenu. Disable „'Fast Timer Modifications -BUGGY' and Disable 'Microsecond Resolution Timer Testing'.

Once you configure the kernel and build it then when you boot up this kernel, it will try to calibrate itself. The calibrated speed can be observed with "cat /proc/cpuinfo". For example, for a 200 MHz Pentium "cat /proc/cpuinfo" should give you:

processor : 0
cpu : 586
model : Pentium 75+
vendor_id :
GenuineIntel stepping : 12
fdiv_bug : no
hlt_bug : no
sep_bug : no
fpu : yes
fpu_exception : yes
cpuid : yes
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 79.67
UTIME cps : 199435298 ticks per second

To add timers with microsecond resolution, set the timer->usec and the timer->expires field appropriately and use "add_timer()" to add the timer. You can test the UTIME subsystem by enabling CONFIG_UTIMER_TEST in the kernel configuration. Enabling this, would add random timers to the timeout queue and measure the time difference between when the timer was supposed to expire and when it actually did. A histogram of this is output to the console using syslog (The printk()'s use KERN_DEBUG as the level, so the messages should be in /var/log/debug, depending on your syslog configuration).

When CONFIG_UTIME is enabled, please use the old timers code (ie a doubly linked list of timers).



III. Implementation and Current Status

UTIME Rapid Reaction Linux is only implemented for the x86 architectures, for processors providing a TSC register, i.e. a Time Stamp Counter
Processor Register.

The restricitions applying for the UTIME patch also apply to Rapid Reaction Linux,
please read therefore the site: UTIME Patch

IV. Acknowledgements

Two Papers have helped us to develop this patch:

  1. Phil Wilshire, Real-Time Linux: Testing and Evaluation, Workshop on Real Time Operating Systems and Applications and second Real Time Linux Workshop, Florida, USA, (2000)

  2. Yu-Chung Wang and Kwei-Jay Lin, Some Discussion on the Low Latency Patch for Linux, Workshop on Real Time Operating Systems and Applications and second Real Time Linux Workshop, Florida, USA, (2000)

Many thanks I due to Prof. Rzehak for support and continued encouragement. Presently Arnd Heursch is working on this project.



V. Bug-reports and Suggestions

Please send all bug-reports/questions/suggestions to arnd.heursch@unibw-muenchen.de . Comments are welcome on how we can improve this system.



Last modified: Mon. Nov. 05, 2001