Re: Language runtime requirements

Re: Language runtime requirements

[agate!spool.mu.edu!news.cs.indiana.edu!drosenfe%motown.ge.com]

>From mikeb@fsi-ssd.csg.ssd.fsi.com (Mike Bates)
>Subject: Re: Language runtime requirements (was Re: DoD
>Date: Fri, 13 Aug 1993 16:06:16 GMT
>
.
.
.
>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.


                                  '''
                                 (o o)
/----------------------------oOO--(_)--OOo------------------------------------\
|    David Rosenfeld       |                          drosenfe@motown.ge.com  |
|    Martin Marietta       |                                                  |
| Gov't Electronic Systems | "Most people die at 25, and wait 40 years to     |
| (formerly GE Aerospace)  |  get buried."  (Ben Franklin)                    |
\-----------------------------------------------------------------------------/

Re: Language runtime requirements

[Mike Bates]

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