This chapter discusses the following:
A real-time program is any program that must maintain a fixed, absolute timing relationship with an external hardware device:
A hard real-time program experiences a catastrophic error if it misses a deadline
A firm real-time program experiences a significant error if it misses a deadline but is able to recover from the error and can continue to execute
A soft real-time program can occasionally miss a deadline with only minor adverse effects
A normal-time program is a correct program when it produces the correct output, no matter how long that takes. Normal-time programs do not require a fixed timing relationship to external devices. You can specify performance goals for a normal-time program (such as “respond in at most 2 seconds to 90% of all transactions”), but if the program does not meet the goals, it is merely slow, not incorrect.
The following are examples of real-time applications:
A simulator or a stimulator maintains an internal model of the world. It receives control inputs, updates the model to reflect them, and outputs the changed model. It must process inputs in real time in order to be accurate. The difference between them is that a simulator provides visual output while a stimulator provides nonvisual output. SGI ® systems are well-suited to programming many kinds of simulators and stimulators.
Simulators and stimulators have the following components:
An internal model of the world, or part of it; for example, a model of a vehicle traveling through a specific geography, or a model of the physical state of a nuclear power plant.
External devices to supply control inputs; for example, a steering wheel, a joystick, or simulated knobs and dials. (This does not apply to all stimulators.)
An operator (or hardware under test) that closes the feedback loop by moving the controls in response to what is shown on the display. A feedback loop provides input to the system in response to output from the system. (This does not apply to all stimulators.)
Simulators also have the external devices to display the state of the model; for example, video displays, audio speakers, or simulated instrument panels.
The real-time requirements vary depending on the nature of these components. The following are key performance requirements:
Frame rate is the rate at which the simulator updates the display, whether or not the simulator displays its model on a video screen. Frame rate is given in cycles per second (hertz, abbreviated Hz). Typical frame rates run from 15 Hz to 60 Hz, although rates higher and lower than these are used in special situations.
The inverse of frame rate is frame interval. For example, a frame rate of 60 Hz implies a frame interval of 1/60 second, or 16.67 ms (.01667 seconds). To maintain a frame rate of 60 Hz, a simulator must update its model and prepare a new display in less than 16.67 ms.
Transport delay is the number of frames that elapses before a control motion is reflected in the display. When the transport delay is too long, the operator perceives the simulation as sluggish or unrealistic. If a visual display in a simulator lags behind control inputs, a human operator can become physically ill. In the case where the operator is physical hardware, excessive transport delay can cause the control loop to become unstable.
Simulators for real or hypothetical aircraft or spacecraft typically require frame rates of 30 Hz to 120 Hz and transport delays of 1 or 2 frames. There can be several analogue control inputs and possibly many digital control inputs (simulated switches and circuit breakers, for example). There are often multiple video display outputs (one each for the left, forward, and right “windows”) and possibly special hardware to shake or tilt the “cockpit.” The display in the “windows” must have a convincing level of detail.
Simulators for automobiles, tanks, and heavy equipment have been built with SGI systems. Frame rates and transport delays are similar to those for aircraft simulators. However, there is a smaller world of simulated “geography” to maintain in the model. Also, the viewpoint of the display changes more slowly, and through smaller angles, than the viewpoint from an aircraft simulator. These factors can make it somewhat simpler for a ground vehicle simulator to update its display.
A simulator can be used to train the operators of an industrial plant such as a nuclear or conventional power-generation plant. Power-plant simulators have been built using SGI systems.
The frame rate of a plant control simulator can be as low as 1 or 2 Hz. However, the number of control inputs (knobs, dials, valves, and so on) can be very large. Special hardware may be required to attach the control inputs and multiplex them onto the PCI bus. Also, the number of display outputs (simulated gauges, charts, warning lights, and so on) can be very large and may also require custom hardware to interface them to the computer.
A virtual reality simulator aims to give its operator a sense of presence in a computer-generated world. A difference between a vehicle simulator and a virtual reality simulator is that the vehicle simulator strives for an exact model of the laws of physics, while a virtual reality simulator typically does not.
Usually the operator can see only the simulated display and has no other visual referents. Because of this, the frame rate must be high enough to give smooth, nonflickering animation; any perceptible transport delay can cause nausea and disorientation. However, the virtual world is not required (or expected) to look like the real world, so the simulator may be able to do less work to prepare the display than does a vehicle simulator
SGI systems, with their excellent graphic and audio capabilities, are well suited to building virtual reality applications.
The operator of a simulator need not be a person. In a hardware-in-the-loop (HWIL) simulator, the human operator is replaced by physical hardware such as an aircraft autopilot or a missile guidance computer. The inputs to the system under test are the simulator's output. The output signals of the system under test are the simulator's control inputs.
Depending on the hardware being exercised, the simulator may have to maintain a very high frame rate, up to several thousand Hz. SGI systems are excellent choices for HWIL simulators.
An example of a control law processor is one that simulates the effects of Newton's law on an aircraft flying through the air. When the rudder is turned to the left, the information that the rudder had turned, the velocity, and the direction is fed into the control law processor. The processor calculates and returns a response that represents the physics of motion. The pilot in the simulator cockpit will feel the response and the instruments will show the response. However, a human did not actually interact directly with the processor; it was a machine-to-machine interaction.
A data collection system receives input from reporting devices (such as telemetry receivers) and stores the data. It may be required to process, reduce, analyze, or compress the data before storing it. It must respond in real time to avoid losing data. SGI systems are suited to many data collection tasks.
A data collection system has the following major parts:
Sources of data such as telemetry (the PCI bus, serial ports, SCSI devices, and other device types can be used).
A repository for the data. This can be a raw device (such as a tape), a disk file, or a database system.
Rules for processing. The data collection system might be asked only to buffer the data and copy it to disk. Or it might be expected to compress the data, smooth it, sample it, or filter it for noise.
Optionally, a display. The data collection system may be required to display the status of the system or to display a summary or sample of the data. The display is typically not required to maintain a particular frame rate, however.
The first requirement on a data collection system is imposed by the peak data rate of the combined data sources. The system must be able to receive data at this peak rate without an overrun; that is, without losing data because it could not read the data as fast as it arrived.
The second requirement is that the system must be able to process and write the data to the repository at the average data rate of the combined sources. Writing can proceed at the average rate as long as there is enough memory to buffer short bursts at the peak rate.
You might specify a desired frame rate for updating the display of the data. However, there is usually no real-time requirement on display rate for a data collection system. That is, the system is correct as long as it receives and stores all data, even if the display is updated slowly.
A process control system monitors the state of an industrial process and constantly adjusts it for efficient, safe operation. It must respond in real time to avoid waste, damage, or hazardous operating conditions.
An example of a process control system would be a power plant monitoring and control system required to do the following:
Monitor a stream of data from sensors
Recognize a dangerous situation has occurred
Visualize the key data, such as by highlighting representations of down physical equipment in red and sending audible alarms
The danger must be recognized, flagged, and responded to quickly in order for corrective action to be taken appropriately. This entails a real-time system. SGI systems are suited for many process control applications.
SGI REACT real-time for Linux® provides the following features:
Linux Trace Tool Next Generation (LTTng) debug kernel to provide trace information for analyzing the impact of kernel operations on application performance. This is the preferred trace tool.
SGI Linux Trace debug kernel to provide trace information for analyzing the impact of kernel operations on application performance. This tool is deprecated and will be removed in a future release.
The react command helps you easily generate and configure a real-time system. See Chapter 9, “REACT System Configuration”.
User-level interrupts to allow you to handle hardware interrupts from a user process.
A frame scheduler that makes it easier to structure a real-time program as a family of independent, cooperating activities that are running on multiple CPUs and are scheduled in sequence at the frame rate of the application.
Note: CPU refers to cores (not sockets).
The most recent version of one of the following operating systems (see the SGI Performance Suite release note for details):
x86-64 Intel® processors with at least 2 cores (4 cores are preferred)
Sufficient memory so that the system can run the operating system and the real-time applications without swapping
For best performance, run REACT on SGI x86-64 servers.
| Note: Real-time programs using REACT should be written in the C language, which is the most common language for system programming on Linux. |
The following RPMs are used for REACT:
cpuset-utils libbitmask libcpuset External interrupts (see Chapter 3, “External Interrupts”):
extint sgi-extint-kmp-* REACT configuration (see Chapter 9, “REACT System Configuration”) and library:
react-utils libreact REACT licensing (for react-utils):
lk