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