Understanding the Latest Open-Source Implementations of Real ...

Technical ViewIt therefore allows all applications implementedon Xenomai skins to run directly on a monolithickernel. In other words, Xenomai 3.0 acts as anabstraction layer over the regular Linux kernel,providing this kernel’s real-time capabilities to itsapplications through the various skins. Xenomai3.0 only requires the standard POSIX API, sothat no patching or porting to particular kernelversions is needed.This gives the developer of applications for Xenomaia useful choice: to run the applications under asmall, lightweight and industry-proven real-timekernel, or under a preemptible Linux monolithickernel. It is important to understand, however,that the second choice means that all real-timecapabilities have to come from – and are only asgood as – the underlying Linux kernel itself.Dual Kernel Versus Native PreemptionEach method has its own benefits. The co-kernelapproach has the advantage that the real-timeapplication is totally independent of the Linuxkernel and only depends on the real-time kernel,scheduler and abstraction layers. There is a clearseparation between the real-time and non-realtimedomain. This simplifies maintenance, timingand safety certification.Porting to new CPU architectures is also easy,because only the abstraction layers have to beadapted. An interrupt abstraction layer patch,however, is always specific to a certain kernelversion, and patches are only available forselected versions of the of the mainline kernel.Under the single-kernel approach with the Linux/PREEMPT_RT patch, a POSIX real-time APIallows real-time applications to be developed inthe GNU/Linux user-space, and to benefit fromall development, debugging and profiling toolsavailable there.At some point in the future, the RT_PREEMPTpatch will be completely merged into the mainlinekernel, and then it will be simple to compile areal-time kernel for any supported system. Then,however, every modification to the operatingsystem, such as kernel patches or new drivers,might influence the system in a perhapsundesired way. Therefore the system will haveto be re-qualified and possibly re-certified aftersuch modifications.Another drawback is that the Linux/PREEMPT_RTentails higher worst-case latencies than adual-kernel system.In the author’s opinion, using the POSIX real-timeAPI is the best answer to the problem of decidingbetween the two approaches. Depending on thespecific requirements of the end product, POSIXreal-time applications can either run on Xenomai’sdedicated real-time kernel or on a single Linux/PREEMPT_RT kernel.Performance Evaluation in the Real WorldSo just how ‘real’ is the real-time performanceof Linux? Below is a method to get a quick firstimpression of the latency of any given system.The tool cyclictest is used to schedule a task withthe highest priority every 10ms. The tool knowswhen this task is expected to run and calculatesthe latency or deviation from this expected time.Table 1 shows the results of a test run on aFreescale i.MX53 ARM Cortex-A8 processoroperating at 1GHz. It ran Linux kernel 2.6.38 fromthe DENX Linux tree. Two different test systemswere set up.S_CPRE: standard kernel withCONFIG_PREEMPT (“Preemptible Kernel(Low-Latency Desktop)) enabled./cyclictest –m -n -p99 -t1 -i10000 -1360000S_XENO: Kernel + Xenomai 2.6.0-rc4 + I-Pipe1.18-03./cyclictest -n -p99 -t1 -i10000 -1360000SystemLatency/µsS_XENOS_CPRE1st runS_CPRE2nd runMinimum 2 27 13Average 43 88 81Maximum 58 415 1829Table 1: Cyclic test of single- and dual-kernel Linux systemsThe average latency shows the typical values thatcan be expected from this system. For developersof hard real-time applications, however, only themaximum latency is of interest. The table clearlyshows the superior performance of a dual-kernelsystem.ConclusionWhen the entire PREEMPT_RT patch has goneinto mainline Linux, it will be the method of choicefor ordinary real-time applications. Xenomai 3.0will then allow easy porting of existingapplications to a single, real-time Linux kernel.A dual-kernel approach will continue to be mostappropriate for hard real-time requirements.For developers of new applications, the use of thePOSIX API is highly recommended whether theyare implementing a single- or dual-kernel system.In the near future, the trend to use multi-coreprocessors will allow for new solutions to theproblems discussed in this article. For example,it is already possible in mainline GNU/Linux toassign interrupts to a CPU core and to keep nonreal-timetasks away from this core. Interestingly,therefore, a multi-core system nullifies theperformance advantage of the dual-kernelapproach. An asymmetric CPU such asFreescale’s Vybrid processor family (using acombination of ARM Cortex-A5 and Cortex-M4cores) offers the option of running multipleoperating systems, each optimised for differentfunctions, to even further improve hard or softreal-time performance.* POSIX is a series of IEEE standards that helpensure compatibility across operating systems bydefining a series of application program interfaces(APIs), functions and command-line shells foruse by the OS. Many embedded OSs are POSIXcompliant,including VxWorks, Linux, MQXand QNX.1.800.FUTURE.1 • www.FutureElectronics.com27