Mr. Dankwardt's article (Real Time and Linux, Part 3: Sub-Kernels and Benchmarks) is a real contribution for the general understanding of Linux and current real-time improvements available.

There are a few clarifications (or points of view) that I would like to express.

First, the RTLinux and RTAI environments, while they do have limited Posix services, are primarily servicable as direct I/O management environments. Synchronization and intra-environment thread operations are available, and data can be pushed and pulled from the Linux environment. But disk, file, networking, and standard I/O, and the broader set of Linux services are not accessible. These environments are not appropriate for the placement of comprehensive applications, such as a complete in-the-loop high end flight simulator applications, or a JVM running process control Java software with responsiveness requirements, etc.

This leads to the benchmark studies. References were made to the excellent performance of RTAI and RTLinux. However, the load that was placed on the Linux environment when measuring Linux responsiveness at the process level was NOT placed on the RTAI and RTLinux environments when measuring RTAI and RTLinux responsiveness. Why not? For the simple reason that that load software CANNOT RUN in such environments! To give equivalent responsiveness measurements, at least some attempt to put a direct load of “important but less critical” activity on the RTAI or RTLinux environment is necessary, to stress the environment and see how the most critical task response is affected…just as was done within the Linux environment to measure Linux process response. The functional equivalent of the RTAI and RTLinux measurements would be to measure Linux process responsiveness while running a load of a single user task doing pure computation without any system service activity. Suffice to say the Linux worst case response numbers would be much better, and quite irrelevant.

Because RTAI and RTLinux are multi-threaded I/O management oriented environments, the equivalent level of software in a Linux environment is the first level interrupt handler of an I/O driver. The key delay factor for both is the worst case interrupt off times of the respective operating system environments. In such head to head competition, Linux actually performs much better than expected. The kernel proper has excellent interrupt off characteristics. There are some I/O drivers available where interrupt off periods are abused…but then how many I/O drivers are even available for RTAI and RTLinux? And it is certainly easy to abuse interrupt off management in those environments as well. Problem I/O drivers for Linux can be avoided or fixed.

I would encourage Mr. Dankwardt to measure and report on interrupt off/first level driver response times in Linux versus RTAI and RTLinux, using (to the degree possible) equivalent loads on the operating environment under test. This will provide much more comparative numbers.

If the argument is made that the load on the Linux environment should not appropriately be put down on the RTAI/RTLinux environments because they are purposefully LINUX loads, that just leads us back to the point that RTAI and RTLinux aren't really meant to be general application environments. And to the point that the equivalent metric is interrupt responsiveness in Linux versus interrupt responsiveness in RTAI and RTLinux. The fact that those just happen to be serviced by “tasks” in RTAI and RTLinux versus “first level interrupt handler” in Linux isn't relevant. These are the functional equivalents that need to be directly compared.

RTAI and RTLinux do solve a problem. They reduce worst case interrupt response by a factor of 2-3x versus Linux proper. And they provide a richer I/O handling environment than that provided for first level interrupt handlers in Linux. They come with a cost of multi-OS complexity and multi-level application design complexity. The ability to solve a real-time requirement more simply in a native Linux environment using the appropriate blend of custom I/O drivers and user level processes should be thoroughly assessed before jumping to a conclusion that RTAI or RTLinux is required.

Again, thanks to Kevin Dankwardt for an excellent characterization overall of these different systems, their attributes and their timing behaviors.

Regards,

Kevin Morgan
VP of Engineering
MontaVista Software Inc.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.