Foreword: In part three of an Embedded Linux Journal series of articles by Kevin Dankwardt on Real-time Linux, Dankwardt reviewed the sub-kernel approach as used in RTLinux and RTAI and provided some benchmark numbers. Following publication of Dankwardt's article . . .

• MontaVista Software's Kevin Morgan issued a response to Dankwardt's article in which he offered “a few clarifications (or points of view)”.
  
• Next, Victor Yodaiken and Matt Sherer (of FSMLabs) reacted to Kevin Morgan's response to Dankwardt's article, taking exception to Morgan's assertion that RTLinux is “not appropriate for the placement of comprehensive applications”.
  
• Then, Kevin Morgan (of MontaVista) clarified the status of MontaVista's kernel preemption enhancements and responded to several other issues raised in Yodaiken and Sherer's earlier comments.
  
• Next, Karim Yaghmour provided the RTAI point-of-view — drawing attention to the nature of the API, the usability of the methods, and distinctions in the overall openness of the specific approaches that are being compared.

In this latest installment of the continuing real-time Linux debate, Doug Locke, TimeSys VP of Technology, contrasts his company's preemptible Linux implementation with that of MontaVista, and comments on several aspects of the preceding debate.

Kevin Dankwardt's article compared three basic approaches to providing predictable support for Linux; the dual-kernel approach represented by RTAI and RTLinux, the standard Linux plus a partially preemptive patch represented by MontaVista, and the fully preemptible kernel approach from TimeSys. While Dankwardt's results are not exhaustive enough to fully clarify the differences between the three approaches, the subsequent comments by Kevin Morgan and Victor Yodaikin seem to have clouded both Dankwardt's results and the actual state of real-time Linux.

Contrary to Yodaiken's comments, a Linux distribution does exist today in which the performance of a real-time thread will not “degrade rapidly” when it is stressed. This is accomplished by providing not only full preemptibility (not disabling preemption whenever resources are shared as with the Love patch), but by providing a fully real-time Linux distribution. TimeSys Linux/Real-Time is far from being just a “proposal” for real-time Linux. TimeSys Linux/Real-Time is a full-featured RTOS being used today for performance-critical applications. Paraphrasing Yodaiken's claim, if you get TimeSys Linux/Real-Time today, you can have a 100-microsecond thread running this afternoon. But with TimeSys Linux/Real-Time, you get this with the standard Linux API; no need for two operating systems, two device driver interfaces, or heroic measures when real-time tasks need to use Linux services such as the file system or socket interfaces.

Additionally, using breakthrough reservations technology, TimeSys lets system engineers move beyond priorities to guaranteed CPU and network interface response, regardless of load levels — also fully complete and available on EVERY board supported. This means that both real-time and non-real-time applications can get predictable performance with dynamic loads and especially overloads.

In other words, TimeSys has, indeed, converted Linux into a system that can be readily configured to provide worst-case response times well below 100 microseconds when needed, and broad performance capabilities when soft real-time response is the requirement, and it can support both of those environments in the same system. It provides this performance with the standard Linux and POSIX application interfaces, and timer resolutions to a few microseconds (depending on hardware available). These features are not restricted to the Pentium and PowerPC, but are available on EVERY board and processor architecture TimeSys supports (e.g., MIPS, SuperH, ARM, StrongARM, SPARC, XScale, Pentium, PowerPC). All of it is available TODAY.

Thus, the software engineering of real-time systems need not be artificially constrained by having two APIs. Configure the application to meet application needs, use the complete, standard Linux API, use the appropriate POSIX interfaces (e.g., SCHED-FIFO threads, mutexes with priority inheritance, nanosleep with microsecond precision), and mix hard, soft, and non-real-time components, meeting every kind of performance requirement.

Regarding Dankwardt's benchmarking efforts, his results are illustrative, but they do not provide a complete picture on the relative differences between the different solutions, because they measure only a few parameters under limited load conditions. In addition, his benchmark results use the TimeSys Linux/GPL version, so they do not show the significant additional performance capabilities available in TimeSys Linux/Real-Time. For additional reading on this subject, an interesting article that further illustrates the differences between the various approaches can be found in the Hourglass project page at University of Utah.

Dr. Doug Locke is Vice President of Technology at TimeSys Corp.

 
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.