Re: What is "real-time"?

[bloom-picayune.mit.edu!mintaka.lcs.mit.edu!spdcc!merk!alliant!russ@bloom- beacon.mit.edu (Russell McFatter)]

In article <1992Oct17.012952.13340@afit.af.mil> mawhelan@afit.af.mil (Michael A
. Whelan) writes:
>Real-time software does not have to be fully deterministic.  It has to
>meet the deadlines of the application domain for a response.  The key is

[...]

> The reason is the responses were
>deterministic.  Even to the guy shooting.  Again, the key is meeting a
>response time requirement for the application domain, not a fully
>deterministic system.  
>
[...]
>
>Mike Whelan
>

No!  When I said "deterministic", of course, I meant time-domain
determinism, not that the code produces the same output (responses) to
different input (stimuli)!

The other suggestions being bantered around ("must produce a result or act
on the data before the required deadline") are also weak, at best.

Put your own personal definitions of "real-time" through the following
quiz:

1:  Is a system "real-time" if it completes processing input data
    substantially faster than it did the same input on a previous "run",
    EVEN THOUGH both attempts met the required "deadline"?

Answer:  NO.  As a real-time developer, you would be as concerned of
    results coming back too early as you would of them coming back too
    "late".  Why?  Because, theoretically, if the system completed the
    processing "quickly" on the faster pass, something unrelated to
    the system itself-- a total unknown-- delayed the "slow" pass.  You
    would be correct to worry that this unknown might cause you to
    miss the deadline at some point in the future.  (Obviously, conditions
    known to the developer-- such as the presence or absence of higher-
    priority tasks, can affect time-to-solution even though they are not
    "unknowns").

2:  Does a real-time system ALWAYS process input in the same
    (deterministic) time?

Answer:  NO.  Many applications' performance depends on the kind or amount
    of data being processed.  The key is that the timing is, at least,
    *predictable*.  That way the designer knows that the system will meet
    the specifications under all of the specified conditions.

3:  Does real-time code always meet its deadlines?

Answer:  NO.  The deadlines are only guaranteed to be met when the work
    meets the criteria that the real-time system is certified for.  The
    specifications may or may not say what is to be done if the deadlines
    cannot be met.  Your phone system, for example, is a real-time system
    to a great extent-- at certain times.  On "older" switches, for
    example, your line was polled about ten times per second when your
    phone was on the hook, to see if you had picked it up or not.  After
    picking up the phone, the system had to provide a dial tone within a
    certain amount of time, at which point the line is scanned about
    100 times per second for dial pulses/DTMF.

    What if every phone on the switch is picked up at once?  Well, that's
    outside the specifications for "real-time" behavior, so the switch is
    free to fall into some kind of backup strategy (resulting in very long
    wait for dial tone, error tone or other message, or perhaps, if this
    situation was not anticipated in the specs, a complete collapse of the
    domestic dial network).

    A real-time application might detect this kind of situation by
    prequalifying the input ("Hmmm...  I count 8 radar targets... I know
    I can't handle that many in the time requirements, so take the first
    6 and put up a warning to the operator"), or by an OS-supplied
    scheduler feature.  For example, a frame scheduler might provide two
    different behaviors on frame overruns-- one preempts the process whose
    frame has ended, thus preventing it from interfering with possibly
    "more critical" processes in adjacent frames; or it might allow the
    process to continue, but send it an "overrun" signal or interrupt
    that it can use to somehow change its behavior ("I haven't been
    counting radar targets, but I'm not meeting my deadline.  I'll start
    ignoring targets beyond a certain distance and will warn the
    operator.")

4:  Parts of a "real-time" system can be nondeterministic, but the results
    can still be considered "real-time".

Answer:  TRUE.  Example:  You have a fairly slow PC running a
    bulletin-board system.  Your *only* specification:  The BBS must allow
    1024-character typeahead at rates of up to 2400 baud, under all
    circumstances.  You collect a username and password, and then access
    a floppy-disk to look up the user information.  This might take
    anywhere from 3 to 30 seconds, and is entirely nondeterministic;
    meanwhile the user might be blasting away at a full 2400 baud.
    HOWEVER: You implemented the serial connection using an interrupt
    handler at a higher priority than the floppy drive; thus no characters
    are lost (even though the floppy access might slow to a crawl).  Your
    BBS meets your own "real-time" criteria despite the fact that the
    non-critical components are nondeterministic.  Of course, if some other
    interrupt is possible at a higher priority (say a mouse or other
    external device), the system no longer meets the "real-time"
    requirements.   If you were requiring *unlimited* typeahead, the specs
    would be a bit harder to meet.

    If you're asking:  How can this setup be considered "real-time" at
    all?  Suppose for the moment that the PC is receiving data once an hour
    from a real-time system that has a deterministic time in which to
    connect to the PC, transmit a username/password and some sort of data,
    then disconnect (regardless of response from the PC) and get on with
    its other work.  

    Simple "real-time" requirements can almost always be faked in hardware
    (by passing off the task to some dedicated device that has nothing
    "better" to do).  Example:  A terminal multiplexor.  It has its own
    buffer, does its own character echoing, and generally won't lose input
    even if the main CPU takes a "long" time to get around to reading
    from it.  You can even bring the entire machine to a stop and the
    multiplexor keeps on handling user input-- to a point...

ip00> mti: duart overrun (059004, -1):

5:  A system is either clearly "real-time" or not, regardless of its
    purpose.

Answer:  FALSE.  You might consider that there is a *scale* to real-time
    events; a range of "legal" nondeterminism for a particular kind of
    event to happen-- an allowable "plus or minus" that is still, for
    "all practical purposes", deterministic.  For example, no computer
    system can be more time-deterministic than its own clock frequency allows
    for.  A credit-card authorization network might be documented to have
    a deterministic response time of "8 seconds" for any successful
    transaction, and "no more than 11 seconds" for any unsuccessful
    one.  It is reasonable to say that an "approved" response will never
    happen in four seconds, or forty seconds, when the system is behaving
    properly-- but, for the purposes intended (to not keep the customer
    waiting), 8.1 seconds might be considered within the "deterministic"
    window, and given the variable delay of the phone transmission itself,
    the variation is unavoidable.


An additional note:

Be very careful when using the word "critical" to discuss real-time
systems and components, because the word has so many meanings.  Example:
which of the following is more "critical"?

1:  A task which controls firing of an automobile's spark plugs
2:  A task which controls the Space Shuttle's brakes in response to
    the pilot's controls

Well, in the first case, the misfiring of a spark plug probably won't
kill anyone.  However, the *timing* is critical-- if off by even a tenth
of a second, the entire engine won't run (or could be irreversibly
damaged).  On the shuttle, a delay of even two entire seconds in applying
the brakes would be unlikely to endanger the mission or anyone on it,
given the length of the runway.  The real-time "scale" and the "failure
penalty" are entirely independent, even though the word "critical" is often
used to described both.

--- Russ McFatter [russ@alliant.com]
std. disclaimers apply.