From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 21 Oct 92 03:58:08 GMT From: munnari.oz.au!metro!seagoon.newcastle.edu.au!wombat.newcastle.edu.au!eepj m@uunet.uu.net (Peter Moylan) Subject: Re: What is "real-time"? Message-ID: <1992Oct21.135808.1@wombat.newcastle.edu.au> List-Id: In article <6095@ucsbcsl.ucsb.edu>, hossein@nu.Berkeley.EDU (Hossein Moiin) wri tes: > > What is real about real-time? What does the word real imply in the > definition of real-time systems? I have wondered about this and I think > that I saw a paper of the same title some time ago. I was wondering if > the real in real-time means that time-axis is treated as a real axis. In the control systems community, there is a tradition of distinguishing between real time and, for example, simulated time. This ties in with the distinction between on-line and off-line algorithms. An off-line calculation is one which can be done before the system starts running, e.g. at the design stage. An on-line calculation is one which has to be done while the system is running because it uses data from the running system. Obviously, there's a relationship between "meeting timing constraints" and "on-line", so to many control people think of "on-line" and "real-time" as synonymous. This is not precisely the way the real-time community thinks of things these days, but I think it does explain the etymology. "Real time" simply means genuine, actual, real time as measured by a clock. It has nothing to do with the meaning of "real" when talking about complex numbers. I think that we're just now beginning to realise that the modern definitions of "hard real-time" are broken, or at least that they're irrelevant to real-time control. Any practical real-time system must have some reasonable robustness properties, i.e. it should degrade gracefully under conditions like a short-duration processor failure. >>From this it seems to follow that a real-time system should not contain any hard real-time deadlines. Of course this does not destroy the usefulness of "hard real-time" as a concept. We can continue to design our scheduling methods while maintaining the fiction that deadlines can be met. We do, however, have to recognise that these deadlines will not be met out in the real world of power surges, sensor failures, and the like. -- Peter Moylan eepjm@wombat.newcastle.edu.au