You are here: Home / RTLWS 1999-2017 / RTLWS Submitted Papers / 
2024-10-08 - 08:00

Real Time Linux Workshops

1999 - 2000 - 2001 - 2002 - 2003 - 2004 - 2005 - 2006 - 2007 - 2008 - 2009 - 2010 - 2011 - 2012 - 2013 - 2014 - 2015

Twelfth Real-Time Linux Workshop on October 25 to 27, in Nairobi, Kenya

How fast is fast enough? Choosing between Xenomai and Linux for real-time applications

Jeremy Brown and Bradly Martin, Rep Invariant Systems, inc., USA

We needed data to help ourselves and our clients to decide when to expend the extra effort to use a real-time extension such as Xenomai; when it is sufficient to use mainline Linux with the PREEMPT_RT patches applied; and when unpatched mainline Linux is sufficient.

To gather this data, we set out to compare the performance of a regular Linux distribution with the performance of Xenomai, a set of patches to Linux that integrates real-time capabilities from the hardware interrupt level on up.

This paper documents our results.  In particular, we provide:

  • a description of the set of tools we developed to test those operating system configurations,
  • difficulties and bugs we experienced in both configuration and testing the two configurations on a specific hardware test platform, the BeagleBoard C4, an OMAP3 (Arm architecture) system,
  • the specific numerical results we got for the BeagleBoard,
  • our conclusions regarding when to use Xenomai vs. stock Linux on the BeagleBoard, specifically,
  • more general conclusions and guidelines for deciding when to use Xenomai vs. Linux (vs. something else entirely) on other platforms.

Our comparisons involve 8 distinct software configurations: a Linux user-space process (as a baseline); a Linux user-space process with realtime priority; a Linux kernel module; a Xenomai user-space process; and a Xenomai kernel module. The Linux configurations are run on both a stock and a Xenomai-extended Linux kernel, so that we can characterize overhead due to the Xenomai patches.

We measure the timing for performing two tasks. The first task is to toggle a GPIO output at a fixed period. The second task is to respond to a changing input GPIO pin by causing an output GPIO pin's value to follow it. For this task, rather than polling, we rely on an interrupt to notify us when the GPIO input changes.

To provide an objective metric, all timing measurements are performed with an external piece of hardware, running a small C program on bare metal.