Dates and Events: |
OSADL Articles:
2023-11-12 12:00
Open Source License Obligations Checklists even better nowImport the checklists to other tools, create context diffs and merged lists
2022-07-11 12:00
Call for participation in phase #4 of Open Source OPC UA open62541 support projectLetter of Intent fulfills wish list from recent survey
2022-01-13 12:00
Phase #3 of OSADL project on OPC UA PubSub over TSN successfully completedAnother important milestone on the way to interoperable Open Source real-time Ethernet has been reached
2021-02-09 12:00
Open Source OPC UA PubSub over TSN project phase #3 launchedLetter of Intent with call for participation is now available |
"Latest Stable" Realtime Linux based on 2.6.26 released
Your new lucky number is 2.6.26.8-rt16
We are glad to announce that the "Latest Stable" version of real-time mainline Linux (aka PREEMPT_RT) is now based on kernel version 2.6.26. We have successfully tested the kernel 2.6.26-8-rt16 in a wide variety of kernel configurations and on many different platforms. We gratefully acknowledge the efforts of the main developers Steven Rostedt and Thomas Gleixner and of the numerous testers and bug reporters who have helped to make this happen.
For the time being, there are no known problems - and the real-time performance of our "Latest Stable" is superb: The above screen hardcopy (click on the image to display it at a higher resolution, click here for an even higher resolution) shows Arnaldo Carvalho de Melo's CyclictestoSCOPE running on a Core 2 Quad system at 2.4 GHz using a 32-bit Linux kernel. After more than 1 million measurement cycles, the internal worst-case latency is only 47 µs - despite running X Window on a hardware-accelerated graphics board and heavy use of the entire system including video and audio playback during more than a day.
Another test system is a 2-way-machine equipped with an Intel Core 2 running at 2.4 GHz. A 64-bit kernel is used. After far more than 2 billion test cycles of thread #1 and nearly 2 billion test cycles of thread #2, we obtain:
T: 0 ( 5234) P:99 I:100 C:2755524664 Min: 5 Act: 9 Avg: 7 Max: 39
T: 1 ( 5235) P:98 I:150 C:1837016454 Min: 5 Act: 8 Avg: 7 Max: 41
which indicates an internal worst-case latency of 39 µs. The following two stress procedures were used throughout the measurement:
# while true; do hackbench 25; done
# while true; do ls -Ral /; done
In addition, the system was flooded continuously with ping packets from another system in the same local network. Could real-time be any harder?
What is new in 2.6.26.8-rt16?
As always, the "Latest Stable" 2.6.26.8-rt16 has a large number of bugs fixed, some of them being introduced since the release of the "Lastest Stable" 2.6.24 real-time kernel, some of them newly discovered (and backported to 2.6.24), and some of them even found in the original mainline Linux kernel. One of the latter is the spurious occurrence of bad page states that Peter Zijlstra fixed in mainline (for details see here) after it was first discovered in a real-time kernel.
In addition to these maintenance fixes, Linux kernels based on 2.6.26 incorporate, among others, two new features that are especially important for us: Device tree support and improved kernel cache management of the video buffer.
Device tree
The device tree was inspired from the Open Firmware project and is a (simple) flat data structure containing information about the devices of a given computer board. The device tree source (DTS) is compiled using the device tree compiler (DTC), and the resulting device tree binary (DTB) is integrated into the boot image. The device tree facilitates board configuration and is required for the merging of the two PPC architecture implementations ppc and powerpc.
Improved kernel cache management of the video buffer
This improved kernel cache management makes it possible for the first time to use hardware-accelerated graphics in a real-time system without any side effects of graphics operations on the real-time capabilities of the system. There is only a minor restriction: Some latencies in the range of several milliseconds occur once when the graphics board is initialized for the first time. Later on, switching to and from graphics or even restarting the X server does not produce any more latencies. Since the initialization of the graphics board can be done at boot time before the real-time critical application is started, this restriction is normally not significant.
BTW: The 2.6.24 -rt tree will be maintained for some time, and fixes will be backported should it be necessary.