Real-time Computing
Hard vs. soft real-time
In general, an operating system is responsible for managing the hardware resources of a computer and hosting applications that run on the computer. An real-time operating system is also specially designed to run applications with very precise timing and a high degree of reliability. This is important in automated process control systems where a delay can cause a critical failure of the overall system. A real-time operating system must have a known maximum time for each of the operations that it performs. Operating systems that can absolutely guarantee a maximum time for these operations are referred to as “hard real-time,” while operating systems that can only guarantee a maximum most of the time are referred to as “soft real-time.” The classical conception is that in a hard real-time system, the completion of an operation after its deadline is considered useless. A soft real-time system can handle such lateness, usually by pausing processes with a lower priority. Most operating systems allow the programmer to specify a priority for the overall application and even for different tasks within the application (threads). In practice, general-purpose operating systems, such as Microsoft Windows, do not always follow these programmed priorities strictly because they are optimized to run a variety of applications and processes simultaneously. The Windows OS uses system interrupts to distribute processor time between different tasks that must access the same shared resources. Standard Linux is also not a hard real-time operating system but it can be made so by using a small high-priority real-time kernel that runs between the hardware and standard Linux. The real-time scheduler of the real-time kernel traps any software-related system interrupts and guarantees that real-time tasks execute with higher priority than normal Linux processes. RTXI uses a real-time thread for actual process control and a non-realtime thread for the graphical user interface.
What can you do in real-time?
A real-time process control system must constantly process a set of inputs and produce a set of outputs. Real-time applications must be carefully programmed to ensure that the total amount of time spent accessing the hardware, sampling the inputs, computing the outputs, and interacting with any user interface is no longer than the specified cycle time. RTAI provides several benchmark tests that allow you to test the general latency of your system. RTXI also has a Performance Measurement plug-in that will help you determine your average and worst case real-time performance within RTXI. The maximum computational rate is not a function of processor speed, but rather the design of the motherboard and the supporting chipset. Reading and writing to a data acquisition board (PCI or ISA) add additional fixed costs. While the processor speed does not directly determine the theoretical maximum computation rate, it does determine how complex of a model can be solved at a given computation rate. Faster microprocessors allow more instructions to be executed per computational cycle. For example, a complex model may require too much computation to work on a 200MHz machine, but will run at 20kHz on a 2GHz machine, even though a much simpler model may only run at 50kHz on either machine. Real-time performance can also be affected by network activity, reading and writing to disk, or graphics that require frequent screen refreshes.
Measures of Real-Time Performance
The “speed” of a platform usually refers to three attributes: time step, jitter, and latency. The target period of the system is called the time step. Ideally this value would be infinitesimal so that we would be able to acquire and output all possible frequencies; however, in practice our time steps are far from this ideal. This is because a lower bound is set by the amount of processing time needed to complete a single input–output calculation. In practice, the actual time step that we observe is a random variable with a mean centered about the target time step. This variation is called jitter, and is a direct result of the non-deterministic nature of modern computer architectures (e.g. cache misses, bus contention, and super-scalar execution). Typically, solutions based on general purpose operating systems will always suffer from high levels of jitter because the underlying system is designed to distribute clock cycles fairly among many competing processes. Latency, the time between receiving an input and updating the corresponding physical output channel roughly determines the lower bound on time step. Latency exists because it takes a finite amount of time to perform analog to digital conversion, do some computation, and convert back from digital to analog. For more information, see:
