How hard is real-time?

The idea and ideal of real-time has become very important to Linux developers. Linux has grown into a full-featured operating system, suitable for many embedded applications. One area that has received a great deal of attention is the potential for using Linux, RTLinux, and RTAI in mission critical applications.

The line between what is real-time and non real-time appears to be a moving target. System developers need to understand the hard floor requirements for real-time. Hard real-time is an absolute deterministic response to an event. It is not based on average response time; this is when hard real-time goes soft. In this article, we will try to demystify the issue of real-time, and clarify the distinctions between hard and soft real-time operating systems (RTOSes).

The grave responsibility of some embedded systems

Embedded systems come in many flavors, each with different requirements. Real-time performance is as diverse as the flavors of the applications the underlying RTOS is asked to serve, and no RTOS can fit all applications. In his recent book about the early American space program “Failure is Not an Option”, Former NASA Flight Director Gene Kranz defines real-time as “. . . when the capsule is electronically in view of the tracking station . . .”

Now this may seem to have very little to do with hard or soft real-time operating systems, but as we explore the analogy, we find they have more in common than immediately obvious. Gene goes on a few chapters later to state that “. . . in real-time controllers knew that if the team made the right decisions, we would accomplish the mission and bring our men home safely. If we were wrong in real-time, we would ruin the mission and the crew might be killed.”

That's a heavy burden for anyone! Unfortunately, it's a fact of life not only for the men who are controllers for the space program, but also for the software and firmware that controls many of the machines we build as engineers. There are deadlines that must be met for certain tasks, say for instance the go/no go decision to abort a mission before the communication window with the spacecraft is over, or to service an incoming data stream before the input buffer overflows or the machine kills someone.

Perception is reality

There are other deadlines that have more to do with perception or throughput where making an absolute deadline is not as important as keeping up with some process over the long term smoothly. Examples of these sorts of real-time system include streaming audio and video where large buffers are put in place to minimize “drop outs” and where occasional buffer under/over runs are non-fatal.

With this in mind, we can start to define what we mean by hard real-time and soft real-time, and it's startlingly simple. In a hard real-time system, the deadlines are fixed and the system must guarantee response within a fixed and well-defined time. In a soft real-time system, we take a best effort approach and minimize latency from event to response as much as possible while keeping throughput up with external events overall.

We've heard much debate about the definition of real-time lately, but this has to be taken as the final answer. For instance, we've heard that hard real-time is just where you draw the line. Some people may call it hard real-time only if it's faster than other people's defined response time.

But if we look at Gene's definition, we see that this really is a red herring. Of course you need to define the response time requirements for your real-time system. However, it is the fact that you have strictly defined those requirements (say, before the spacecraft goes out of view or before the shaft on the motor you're controlling turns more than 0.3 degrees) that have made your system hard real-time as opposed to soft real-time.

Real-time on the moon

But back to OSes, and specifically RTOS definitions. From all of this, it's clear that a hard real-time OS is one that provides a guarantee that the response to an event will occur within some fixed time, without fail no matter what. A soft real-time OS will do it's best to service your event in, on average a certain time. Both types of OS are useful, but they have distinctly different uses. And in fact, a hard RTOS usually provides scheduling classes for tasks requiring both hard and soft real-time response.

In Gene's account of the first moon landing, we find that the guidance computer on the Eagle, the Apollo 11 Lunar Module, had both hard and soft real-time tasks (and this is more than 30 years ago)! During decent, the Lunar Module's computer was unable to keep up with the data stream from the landing radar, a non-critical task. These missed deadlines were non fatal, and the scheduler automatically reset and the mission proceeded normally. On average, most of the landing radar data (and other tasks for that matter) met the required deadlines to guide the craft to a safe landing.

Now, it may well be that the Lunar Module landing radar task was intended to be hard real-time, and its failure turned out to be soft in practice, but that's not really the point. It illustrates the differences involved, and from there we can extrapolate a useful system incorporating both concepts.

An earthly example

Let's look, for instance, at a fairly typical data acquisition system which is also called upon to process the data it receives. We can ease design constraints by partitioning the system into three separate domains: hard real-time, soft real-time, and non real-time.

Suppose that we have a data stream coming in from an analog to digital converter, and that this converter absolutely requires us to read its output every 125uSec. This is simple hardware, possibly a high resolution Delta Sigma A/D with only a single sample of output buffer.

We can use a hard real-time task to read the converter into a buffer in memory, safe in the knowledge that no matter what other demands are placed on the system, even ones that where unforeseen when the system was designed, every sample will be read from the converter into a memory buffer.

We can then use a soft real-time task which will on average have the required throughput and low enough latency to process the buffer stored by the hard real-time task. We know that we will keep up with the data stream which has been safely stored for the soft real-time task even though we may not be able to guarantee we get to each and every sample before the next comes in.

Finally, we can take the post-processed data from the soft real-time task and display it on a console of some kind.

The hard and soft side of Linux

Hard and soft real-time systems have different requirements, and both may (and usually do) exist in the same system. There are systems, which can get by with only soft real-time, whereas there are those where it is absolutely fatal to miss deadlines and which are therefore hard real-time by their very nature.

Linux based RTOS solutions are available for all of these classes of system — accommodating simple problems requiring a few milliseconds average soft real-time response, to strictly defined and highly demanding systems requiring 15uS guaranteed response times with only 5uS of jitter (available with RTAI). By meeting such a broad range of system requirements, Embedded Linux comes very close to being a universally applicable RTOS.

---

Author's bio: Jeff Dionne was a co-founder of Rt-Control Inc., with over 15 years of experience working in the electronics and software industries. His strengths include software and electronics hardware engineering. Dionne's work experience is in the computer networks, electronic services and manufacturing industries. He has been involved with many software and hardware companies as a lead developer or project engineer. His list of projects includes development of a Data Concentrator/Port Server, Digital Fault Playback system, Precision DSP power meter and 30KW power amplifier for Automated Test Equipment. Dionne was the co-developer and is the maintainer of the uClinux operating system, and his contributions to the Open Source community are well recognized. In February 2000, when Rt-Control was acquired by Lineo, Inc. Dionne became part of the Office of the CTO, and VP of Research and Development.

---

 
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.