I recently installed the latest version of the Enhanced Machine Controller (EMC) software for my Sherline milling machine. Unlike previous versions, the EMC code now runs happily in standard Ubuntu Linux with RTAI generating hard real-time stepper motor control signals. You can even stream Internet music and gnaw metal without missing a beat or crashing a cutter.
The Mobile and Embedded Linux track of the April LinuxWorldExpo presented the current state of the real-time Linux kernel effort and, en passant, showed why kernel patches may trump a separate real-time layer for most applications. After some poking around, I think I now understand the implications of the two approaches and, as usual, the technical aspects have less to do with the outcome than you might expect.
But the tech makes a nice starting point, so I'll begin there.
The Many Faces of Real-Time
In June 2005, Paul McKenny posted a note to the Linux Kernel Mailing List summarizing seven different ways of getting real-time performance from the Linux kernel. Although he expected a flame fest, the responses indicate that he'd accomplished that most difficult feat—explaining a contentious topic without offending anyone.
The methods range from simply using the stock kernel, for applications with very relaxed timing requirements, to a single OS image distributed across multiple real or virtual CPUs, with one or more dedicated to real-time threads. It seems most techniques have strong partisan support, coupled with a nearly complete lack of comparable measurements to support decisions.
While describing the real-time kernel patches, Sven-Thorsten Dietrich showed results at LWE indicating that the stock 2.6 kernel can respond to an external interrupt within a few milliseconds, Montavista's fully patched 2.6 kernel on an 800-MHz Celeron can provide 100- to 200-microsecond latency, and a 3.2-GHz Pentium pushes that down to 65 s.
The lowest latency can be just a few microseconds if the interrupt occurs at precisely the instant when the kernel's state allows an immediate response. The jitter between the fastest and slowest response thus nearly equals the worst-case latency, which can rubbleize an algorithm that depends on regular timing in the real world.
For example, the stock kernel can sample an external voltage every 500 ms with no trouble at all: The jitter would be 1 percent of the sample interval. Cranking the sampling interval to 50 ms, however, raises that same jitter to 10 percent of the nominal period. The digital representation of an analog signal sampled with that amount of jitter would bristle with spurious frequency components.
The next step in McKenny's taxonomy describes a nested OS, with a real-time OS running a nonreal-time Linux kernel as a separate task. That's the general idea behind RTLinux, RTAI, and Adeos, although each applies a different mindset.
A separate hard-RTOS kernel provides latency in the 10-s range for moderately peppy x86-class CPUs, with correspondingly reduced jitter. Sampling a signal every 1 ms with 1-percent jitter becomes entirely feasible, although communication between tasks on different OSes may be difficult, depending on how they're lashed together. As always, stability and ease of communication vary inversely.
The remainder of McKenny's list includes the dual-OS approach, which runs an RTOS on one CPU and Linux on another, a parallel-OS mechanism that moves tasks between real-time and nonreal-time kernels running on the same CPU, and the bizarre (to me, anyway) single-image/multiple-CPU kernel that hasn't been implemented yet.
In short, the answer to the question of whether Linux provides real-time performance depends on what, exactly, you mean by real-time. For any latency requirements over a few tens of microseconds, you can find some combination that will work for you.
