Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.arch
Subject: Re: RISC != real-time control (actu
Message-ID: <46500015@uxe.cso.uiuc.edu>
Date: 9 May 88 19:19:00 GMT
References: <1091@daisy.UUCP>
Lines: 46
Nf-ID: #R:daisy.UUCP:1091:uxe.cso.uiuc.edu:46500015:000:2724
Nf-From: uxe.cso.uiuc.edu!mcdonald    May  9 14:19:00 1988


>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.

Sometimes microseconds can matter. Our most complicated real-time
system runs a scanning interferometer and a laser. The interferometer
is a mechanical plunger riding in a sleeve 0.00025 inch larger in
diameter than the moving part, at a temperature of -196 Kelvin, on
a cushion of pressurized helium.  The "wiggle" tolerance on the motion
is +- 0.000005 inch. This can only be achieved if the motion is smooth;
this part is taken care of by servo hardware. This hardware detects
the position of the mirror mounted on the plunger by counting 
interference fringes of a laser. It sends signals to the computer every
100 microseconds. The computer converts several error signals from
the hardware and decides if they are within tolerance. If not, it skips
a data point. If they are OK it starts the complicated process of
firing the various parts of the laser so that the sixth anticipated
trigger signal will occur just at the time the laser is really ready to 
go; the actual firing is by hardware. The computer again checks to see
if the collected data is OK or garbage. Then it can start over again.
The computer also checks on the "quality" of the servo loop inputs;
if they get weak the moving parts have been known to self-destruct
($5000) - there are hardware "stops" to prevent destruction, but 
using them ruins the alignment and we have to warm up to room 
temperature to fix it, a three day process. We are using a PDP-11/73,
with ALL interrupts disabled. The program was written in assembler,
checking the timing of every instruction -- we can see by its outputs
on a scope how much time we have to spare, and of course there are
variations due to the cache hit/not hit probability, but we know
FOR SURE that it won't overrun, as we give it 25% to spare, in the worst
case. The code was an absolute nightmare to write, but it is actually
rather simple , in fact only about 3000 lines.
        I would consider this to be "real-time".
Doug McDonald