Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!hplabs!decwrl!sgi!daisy!david
From: david@daisy.UUCP (David Schachter)
Newsgroups: comp.arch
Subject: Re: RISC != real-time control (actually a note on needs of real-time)
Message-ID: <1091@daisy.UUCP>
Date: 27 Apr 88 18:19:05 GMT
References: <1521@pt.cs.cmu.edu> <1534@pt.cs.cmu.edu>
Reply-To: david@daisy.UUCP (David Schachter)
Organization: Daisy Systems Corp., Mountain View, Ca.
Lines: 41

In article <1534@pt.cs.cmu.edu> schmitz@FAS.RI.CMU.EDU (Donald Schmitz) writes:
>In article <1521@pt.cs.cmu.edu> koopman@A.GP.CS.CMU.EDU (Philip Koopman) writes:
>>Real-time control programs often have a situation where only
>>X microseconds are available to perform a task.  Therefore,
>>the code to perform the task must be GUARANTEED to complete
>>within X microseconds.  In real-time control, a late answer
>>is a wrong answer.
>
>This may be straying somewhat from the original point, but what sort of
>applications really have such exact timing deadlines?...
>[I]n general a few percent deviation in cycle
>time has next to no effect.  As long as the deviation is small and well
>distributed, ie.  delays of no more than 20% and occuring less than 10
>sample periods in a row, I can't imagine a mechanical system reacting to the
>error.

Not all real-time system control mechanical objects.

I wrote code for a radio-controlled clock.  The microcontroller takes a non-
maskable interrupt every millisecond.  If the interrupt service routine ever
takes more than a millisecond to execute, the results are:

1) The stack may get trashed, or it may not.
2) The clock will lose a millisecond.
3) Certain I/O ports may not be completely updated.
4) The clock may lose an output character (sending time to the host)
5) The clock may lose input characters (receiving commands from the host.)

Depending on the customer's usage of the clock, the result could be a simple
as a traffic light "slipping" a millisecond" or as bad as a wide-area network
losing packets and not being able to restart after a network crash.

I put in code to reset the clock if nested NMI's occur and I spent a lot of
time counting clocks and doing measurements with an oscilloscope, to insure
the interrupt service routine will alway take a less than a millisecond.
Worst case time: 900 microseconds.  Usual case: 100 microseconds.

Before the work, the clock would often crash for no apparent reason.  Turned
out the previous programmer (this is two years ago) was allowing the ISR to
take more than ten milliseconds (i.e. nesting NMI's ten levels deep!)

Disclaimer: this article was written by Schroedinger's cat, Bill.