From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=1.0 required=3.0 tests=BAYES_20,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 20 Aug 93 16:03:34 GMT From: fsi-ssd!mikeb@uunet.uu.net (Mike Bates) Subject: Re: Language runtime requirements Message-ID: List-Id: In article <9308171458.AA00395@ivory.motown.ge.com> drosenfe@motown.ge.com writ es: >We had a few problems with the environment -- device drivers were >written for transaction-processing "real-time," not for hard >real-time. Could someone please explain the difference between transaction-processing real-time, and "hard" real-time. The comp.realtime FAQ contains a full-page discussion on how to define "real-time." The following paragraph from that document may help explain what I mean by transaction-processing real-time. One will occasionally see references to "real-time" systems when what is is meant is "on-line", or "an interactive system with better response time than we used to have". Often, this is just marketing hype. For instance, although some have queried whether running "rn" is real-time, it is not, as it is interacting with a human who can tolerate hundreds of milliseconds of delays without a problem. Similarly, on-line stock quotation systems interact with humans. Transaction-processing systems like automatic teller machine networks, airline reservations systems, and stock quotation systems are "real-time" in the sense that they must respond promptly, but there is some slack -- an unusually long disk access time wouldn't cause a problem. Let me try to illustrate hard real-time by describing the way flight simulators work. A typical flight simulator consists mostly of algorithms which model various aircraft systems. Every 33 millliseconds (to take a typical number) an I/O system is polled to get the state of input devices (control columns, throttles, buttons, switches), then the aircraft algorithms are executed using these inputs, which determines the state of the outputs (visual display, flight instruments, hydraulic motion platform, lights, buzzers, etc.) Many algorithms perform integrations, using the time per iteration, or frame (33 msec in this case), as a basis for calculation. All of these calculations must be completed within 33 msec. (Or less -- there has to be time for background tasks to run, and there is usually a spare-time requirement.) If the calculations overrun the frame, the simulator will react more slowly than the aircraft would, decreasing the quality of the training provided by the simulator. Customers and certifying agencies (such as the FAA in the US) are very picky about simulator performance matching aircraft performance. Even a noticeable lag between flipping a switch and seeing the light go on would be grounds for withholding approval. In my earlier post, I mentioned that the VAXELN device drivers weren't efficient enough to meet hard real-time requirements. The problem was that we were required to run at 60 Hz (frame time = 16.67 msec) with 50% spare time. We had to transfer data each frame over serial lines to a motion controller and over a parallel interface. The VAXELN drivers for both of those devices (1) were eating up too much of our alloted time and (2) weren't deterministic w.r.t. execution time, i.e., we couldn't guarantee that they would finish their work within one frame. Transaction-processing applications can live with slight delays and interrupts; hard real-time applications can't. -- ------------------------------------------------------------------------------ Mike Bates FlightSafety International, Simulation Systems Div. Principal Engineer 2700 North Hemlock Circle Computer Systems Group Broken Arrow, Oklahoma 74012 mikeb@ssd.fsi.com 918-251-0500 ext. 581