| A Response to "Real Time and Linux, Part 3" |
Kevin Morgan (May 2, 2002)
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.
Talk back! Do you have a comment or question about this story? talkback here
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Linux is a registered trademark of Linus Torvalds. All other marks are the property of their respective owners.
news feed