duncant@mbunix.mitre.org (Thomson) (02/23/90)
Someone asked me recently what real-time really means. After some thought,
I answered that real-time systems were simply those {in which the
timing constraints were so tight that speciall programming techniques
were required. Under this definition, a "real-time" system of today may
become a non-real-time system whan hardware gets fast enough that I can
program it using any regular old operating system (say plain old UNIX)
using high level language (no assembly language optimization) and not have
to worry about my software failing to meet its deadlines.
~rk
Anyone care to comment? What is the best definition of real-time?
Duncan Thomsondstewart@fas.ri.cmu.edu (David B Stewart) (02/24/90)
In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: > >Anyone care to comment? What is the best definition of real-time? > By far the best definition I have seen about "What is real-time?" is the following: "A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. " (original author unknown) E.g. The computation 1 + 2 must be known by time t = 2 seconds, even if the answer of "3" arrives at t = 2.2 seconds, it is wrong because it is late! If the timing constraints of the system are not met, system failure is said to have occurred. Hence, it is essential that the timing constraints of the system are guaranteed to be met. Guaranteeing timing behavior requires that the system be predictable. It is also desirable that the system attain a high degree of utilization while satisfying the timing constraints of the system. Just like there is the monthly posting on comp.unix.questions of Often-asked questions; there should be a monthly posting in this newsgroup answering the question "What is Real-Time!" :-) -- David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, Carnegie Mellon University, email: stewart@faraday.ece.cmu.edu The following software is now available; ask me for details CHIMERA II, A Real-time OS for Sensor-Based Control Applications
marks@tekigm2.MEN.TEK.COM (Mark D Salzman) (02/24/90)
In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: > What is the best definition of real-time? A definition that has served me well for a "real-time" system is as follows: A "real-time" system is one where the response time to any given event (an interrupt or other asyncronus signal) is predictable and repeatable. In other words, when an interrupt happens on a "real-time" system, the ammount of time it takes to handle that interrupt can be calculated and will always be the same (within limits). Anyone got a better idea? -- # Mark D. Salzman Phone: (206) 253-5542. # The more complex the mind, # Tektronix Inc., P.O. Box 3500, M/S C1-936 # the greater the need for # Vancouver, Washington. USA 98668 # the simplicity of play. # E-MAIL: marks@tekigm2.MEN.TEK.COM # James T. Kirk
lmb@vicom.com (Larry Blair) (02/24/90)
In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes:
=
=
=Someone asked me recently what real-time really means. After some thought,
=I answered that real-time systems were simply those {in which the
=timing constraints were so tight that speciall programming techniques
=were required. Under this definition, a "real-time" system of today may
=become a non-real-time system whan hardware gets fast enough that I can
=program it using any regular old operating system (say plain old UNIX)
=using high level language (no assembly language optimization) and not have
=to worry about my software failing to meet its deadlines.
=~rk
=Anyone care to comment? What is the best definition of real-time?
One can say that realtime means running fast enough to meet your time
constraints, but to me there are two things that all realtime systems
share: determinism and low latency. UNIX is definitely not deterministic
and the only way to get low latency is to put time critical code in the intr
routine.
--
Larry Blair ames!vsi1!lmb lmb@vicom.commerriam@csuchico.edu (Charles Merriam) (02/24/90)
Realtime means that your response time will be appropriate for
the equipment/users of the module. For example, a real-time ATM controller
needs an account balance within five seconds, since that is appropriate to
the user. A square root operation may require a response within five
milliseconds if used as a critical part of a flight control system.
One could argue that all computer programs have real-time constraints,
but it would not improve preformance.
Charles Merriam
Calif. State University, Chico
----
"If it is underbudget, ahead of schedule, works the first time, and
can be modified by a two year old, then it is art." merriam@csuchico.eduChris.Holt@newcastle.ac.uk (Chris Holt) (02/25/90)
In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: > > >Someone asked me recently what real-time really means. After some thought, >I answered that real-time systems were simply those {in which the >timing constraints were so tight that speciall programming techniques >were required. Under this definition, a "real-time" system of today may >become a non-real-time system whan hardware gets fast enough that I can >program it using any regular old operating system (say plain old UNIX) >using high level language (no assembly language optimization) and not have >to worry about my software failing to meet its deadlines. >~rk >Anyone care to comment? What is the best definition of real-time? > >Duncan Thomson This fails to take into account (i) systems that have to wait for specified periods, and (ii) proofs that given programs are in fact "fast enough". I would define real-time programs as ones in which time is a necessary component of the specification. It can be broken down into "hard" real-time, where the price of missing a deadline is catastrophic, and "soft" real-time, where the cost is smooth over time. _______________________________________________________________________________ Chris Holt, Computing Lab., U. of Newcastle | Chris.Holt@newcastle.ac.uk _______________________________________________________________________________ "I will show you fear in a handful of bits..."
duncant@mbunix.mitre.org (Thomson) (02/26/90)
I read with interest the responses to my question "What is 'real-time' really?". The definitions seem to contain various combinations of the following criteria: 1. Real-time systems must provide answers by some specified time. 2. The time response of the system must be "deterministic", i.e. one must be able to be certain that functions will be performed within specified time limits. I have a couple of problems with these definitions. First, it is not enough to say that a real-time system is one which must provide answers by a specific time. Consider a company's payroll system, which absolutely must compute the pay of each employee by the 29th of the month (otherwise all hell breaks loose). This system has "hard" timing requirements, but I doubt that many people would want to consider it a real-time system. There are plenty of other examples, with time scales ranging from very short to very very long. Where does one draw the "real-time" line? Second, I don't like the "deterministic" answer too much either, mainly because I doubt that there are many "real-time" systems out there which are really deterministic. One of the net responses raised the issue of "proving" that the system can meet its time constraints. Given the current state of the art, I doubt that there are any real real-time systems which have actually be formally proven to be able to meet their timing requirements. Or are there? I still stick to my definition (until I get convinced of the error of my ways by some of you experts out there) that "real-time" means "timing constraints so tight that you have to use special programming techniques to meet them." (I also have a definition for AI: Problems so hard that you can't solve them using conventional programming techniques - but that's another discussion.) At least I seem to have generated some action on this sleepy interest group! Duncan Thomson
gregw@otc.otca.oz (Greg Wilkins) (02/26/90)
Definition of "REAL TIME"????? Well I think that the answer "a system where the answer is wrong if it is late", is not correct. This definition includes weather forcasting systems which must produce an answer in less than 24 hours (otherwise it is a weather verification :-). The best definition I have seen (and I think it should be inlcuded in a regular "frequent answers" posting) is: "Real time systems are ones in which 'time' is an explicitly managed resource." - Author unknown. -gregw
rks@kurki.tut.fi (Kurki-Suonio Reino) (02/26/90)
In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes: >Someone asked me recently what real-time really means. After some thought, >I answered that real-time systems were simply those {in which the >timing constraints were so tight that speciall programming techniques >were required. Properties like this should best be understood as properties of models, not of "real" systems. Of course, they can then be used of "real" systems also, whenever the associated models are found useful in their description. The question, whether a payroll system, for instance, is real-time, therefore reduces to the question, whether real-time description techniques offer any advantages for it. Before trying to define real-time I think it is important to make the distinction between "transformational" and "reactive" systems, as Pnueli, for instance, does. A transformational system is supposed to compute a final result on some input data, while a reactive system maintains continued interaction with its environment. Real-time systems belong to the latter category, which cannot even theoretically be reduced to transformational systems. For transformational systems it makes sense to talk about their efficiency, but even with stringent time requirements they would not be real-time. When the specification of a reactive system determines the computations that are possible in the system, there are two basically different ways to deal with time requirements. One is to understand them as efficiency requirements that are outside the basic model of execution. A computation may then depend on whether some time limits are met or not, but there is a possible computation in both cases. The term (soft) real-time seems to refer to these systems, where computations depend on the real time. The other possibility is to preclude totally the missing of some deadlines. In that case the model defines no computations for such cases, and it is the implementor's task to guarantee that an implementation has only computations that are defined in the specification. This seems to be what is meant by (hard) real-time. Comments? Reino Kurki-Suonio
dstewart@fas.ri.cmu.edu (David B Stewart) (02/27/90)
In article <98987@linus.UUCP> Duncan Thomson writes: > >1. Real-time systems must provide answers by some specified time. > >2. The time response of the system must be "deterministic", i.e. one must > be able to be certain that functions will be performed within specified > time limits. > I definitely agree. >I have a couple of problems with these definitions. > >First, it is not enough to say that a real-time system is one which must >provide answers by a specific time. Consider a company's payroll system, >which absolutely must compute the pay of each employee by the 29th of the >month (otherwise all hell breaks loose). This system has "hard" timing >requirements, but I doubt that many people would want to consider it a >real-time system. There are plenty of other examples, with time scales >ranging from very short to very very long. Where does one draw the >"real-time" line? That's a good question. I would probably say the system is non-realtime because there is a human that issues the command "Print pay checks". If the system was completely autonomous, and there was never any humans involved, then it would be a real-time system. In such a case the system would have to make sure the checks are printed on time, but it cannot do them too early because additional employee information, such as sick days, new employees, etc. may cause the value of the check to change. These timing constraints will then make the system real-time. However, because we are talking on the order of magnitude of "days" instead of seconds, most computer systems are fast enough to handle this task using a conventional operating system, only because they have so little to do compared to the amount of time they have; what if that one computer had a million things to do, in a very specific order; would it succeed? That all depends on how it is programmed ... and at that point it would be a real-time system. One note about real-time systems: Few problems occur on under-used systems, since there is enough time to do everything. The timing constraints start to cause problems on a system that is running at near capacity. Because applications running on the order of milliseconds are much more likely to be hitting the full bandwith of the CPU then an application running on the order of days (it takes lots and lots of stuff to keep a computer busy for days non-stop), they are the ones most likely to require the special real-time techniques ... i.e. considering time as an important factor in all equations. > >Second, I don't like the "deterministic" answer too much either, mainly >because I doubt that there are many "real-time" systems out there which >are really deterministic. Can you imagine an airplane on auto-pilot with nondeterministic performance? Can you imagine the system controlling a production line that cannot guarantee that everything stays on schedule; what would your car look like if the robot welds the doors shut because it was late in starting the job? The "true" real-time systems are deterministic; those systems that are not deterministic still require work until they are. Nobody wants to buy a non-deterministic system, who knows what it might do! :-) >One of the net responses raised the issue of >"proving" that the system can meet its time constraints. Given the current >state of the art, I doubt that there are any real real-time systems which >have actually be formally proven to be able to meet their timing requirements. >Or are there? The "proving" part is the tough one. Too many of todays real-time systems have been developed ad-hoc, just testing and hacking code until it works right; it is not really possible to prove that they work right, thus something can go wrong. Much of the research into real-time systems is to remove this ad-hoc method of creating systems, and replacing them with straightforward programming practices, that provably have deterministic results in all situations. > >I still stick to my definition (until I get convinced of the error of my >ways by some of you experts out there) that "real-time" means "timing >constraints so tight that you have to use special programming techniques >to meet them." The only special technique you need is to consider time into any algorithms that you develop; the big question is how to you consider it? Take as an example an iterative Numerical-Methods algorithm In a non-realtime environment you would say, "Iterate until error less than 0.00001" whereas in the real-time environment you might say "Iterate until error less than 0.00001 OR time > 0.3", in which case the iteration may stop at slightly lower precision, but at least it is on time to pass on to the part of the system that needs it. But is this the best way? What if the non-precise answer is not good enough, is this method of including time sufficient? What about for all those applications which are non-iterative, what do you do then? Those are the questions that are being asked by real-time system designers, all in the quest of making real-time system design much easier and much more predictable than the old days of trial-and-error. ~dave -- David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, Carnegie Mellon University, email: stewart@faraday.ece.cmu.edu The following software is now available; ask me for details CHIMERA II, A Real-time OS for Sensor-Based Control Applications
ylee@mcrware.UUCP (Yeongleh Lee) (02/27/90)
After read several excellent postings about "What is real-time really"
in this news group, I am not going to give best definition of real-time,
since every definition I saw in this news group is good in a certain point
of view. I just state the difference between realtime and non-realtime as
I can feel.
Standard UNIX, designed as a time sharing system, is not considered
as a real time system. For example, the UNIX kernel is not preemptible.
A low priority task in a system call can not be preempted to allow a
critical task to response to an external event. This will be serious
for those systems really need real time such as space shuttle, nuclear
energy plant, robot,.. etc. Even several milli seconds is important.
For program development, non-realtime system may be deemed good enough
since real time is not important. However, realtime programming and non-
realtime programming won't be the same.
So one characteristic of real time system is "Priority-based preemptive
scheduling of tasks to ensure that the task of highest priority is executed
when it becomes runnable".
Another characteristics of real time system is "Direct control of the
scheduler by user processes to guarantee the execution of the appropriate
task".
Compare realtime systems such as OS-9, OS-9000, VRTX, and VxWorks
v.s. UNIX, one can find there are differences between realtime and non-
realtime systems.
Yeongleh Lee
uunet!mcrware!yleeisr@rodan.acs.syr.edu ( ISR group account) (02/27/90)
How about: Real-time systems are those in which when looking at the states it goes through s1..s2...s3..s4..s5..s6..s7.. etc, it is required that the system be in a particular state Sn withing a time Tn of an event En. This seems to hold whether your talking about a balance being returned within 5 seconds of a ATM request, or a value being output within half a microsecond of a sensor firing, or even a payroll program finishing within 3 hours of it's starting time. (After all, if it's going to be run at midnight thursday night and has to be done by 3:15 am to print the checks, its real-time) On the other hand, if a system doesn't guarantee this, then I can't see how it could be considered real-time. Mike Schechter msschech@rodan.syr.edu Systems Engineer Institute for Sensory Research isr@rodan.syr.edu -- Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ. InterNet: isr@rodan.acs.syr.edu Bitnet: SENSORY@SUNRISE
leguerni@irisa.irisa.fr (Paul Le Guernic) (02/28/90)
From article <98692@linus.UUCP>, by duncant@mbunix.mitre.org (Thomson): > > > Someone asked me recently what real-time really means. After some thought, > I answered that real-time systems were simply those {in which the > timing constraints were so tight that speciall programming techniques > were required. Under this definition, a "real-time" system of today may > become a non-real-time system whan hardware gets fast enough that I can > program it using any regular old operating system (say plain old UNIX) > using high level language (no assembly language optimization) and not have > to worry about my software failing to meet its deadlines. > ~rk > Anyone care to comment? What is the best definition of real-time? > > Duncan Thomson
leguerni@irisa.irisa.fr (Paul Le Guernic) (02/28/90)
From article <98692@linus.UUCP>, by duncant@mbunix.mitre.org (Thomson): > > > Someone asked me recently what real-time really means. After some thought, > I answered that real-time systems were simply those {in which the > timing constraints were so tight that speciall programming techniques > were required. Under this definition, a "real-time" system of today may > become a non-real-time system whan hardware gets fast enough that I can > program it using any regular old operating system (say plain old UNIX) > using high level language (no assembly language optimization) and not have > to worry about my software failing to meet its deadlines. > ~rk > Anyone care to comment? What is the best definition of real-time? > > Duncan Thomson Excuse me for the previous empty posting. A real time system could be defined as a system which continuously interacts with an environment characterized by dynamic properties, modifying its behavior and being modyfied by it. In this meaning, real-time can not be reduced to hardware performance : put an iPSC to control a train and you will still have to meet real-time constraints (don't close the door before anyone is entirely entered, don't crush the passengers with too many G's, adapt the speed to the railroad configuration,...). So a real-time system has to supply the user with the ability to compute time values; and it mainly has to be deterministic ! Some languages have been defined in France (ESTEREL, LUSTRE and SIGNAL) to meet this requirement; these synchronous languages assume that an event may handle more than one communication and, moreover, computing values is assumed to spend no time. It is the way to get deterministic computing upon time. Meeting of time constraints may then be proved depending upon properties of the architecture used to implement the real-time application. Paul Le Guernic
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (02/28/90)
> First, it is not enough to say that a real-time system is one which > must provide answers by a specific time. Consider a company's > payroll system, which absolutely must compute the pay of each > employee by the 29th of the month (otherwise all hell breaks loose). > This system has "hard" timing requirements, but I doubt that many > people would want to consider it a real-time system. Why not? The system can be considered to have failed if the time constraint is not met. The only reason that I can see for not considering the payroll system (or your nervous system for that matter) a "real time" system is hidebound thinking -- if it ain't exclusively chips and wires, it ain't a System. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------
james@phred.UUCP (JAMES Taylor) (02/28/90)
In article <1318@otc.otca.oz> gregw@otc.UUCP (Greg Wilkins) writes: >Definition of "REAL TIME"????? > >Well I think that the answer "a system where the answer is wrong if it is >late", is not correct. This definition includes weather forcasting systems >which must produce an answer in less than 24 hours (otherwise it is a >weather verification :-). .... > >"Real time systems are ones in which 'time' is an explicitly managed >resource." - Author unknown. This being the second article I've seen purpetuating the same fallacy, I had to comment. This is obviously a real time system. It simply is not a useful example of such a system, in the context of a discussion of the special problems involved in a real time system design. In the same way, boolean logic is not an apprioprate description until the timing scale is such that you do not need to design in that infinite analog inbetween. Perhaps a useful extension of the defininition would be: Real time systems are ones in which 'time' is a critically managed resource. ^^^^^^^^^^ Time is clearly explicitly managed in the system example - However it was managed via checkbook at the installation of the system, rather than by the designer of the system specifically to provide management of time. A real time system (as has been stated before) is characterized: 1) Management of processes parameterized in part by time 2) Ability to recognize that a process has failed to meet time requirements James Taylor
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/01/90)
> A real time system could be defined as a system which continuously > interacts with an environment characterized by dynamic properties, > modifying its behavior and being modyfied by it. I find this definition in one sense too vague. Which systems are in a totally static environment? In another sense too far out. Do we have to have self-modifying systems to have real time systems (the modifying its behavior part above)? I think that "time being explicitly and explicitly managed resource" is my favorite in the string so far. --- Ben
mac@ra.cs.Virginia.EDU (M. Alex Colvin) (03/02/90)
real-time systems react to time, a continuous variable. because responses take time, the response is approximate. a characteristic of real-time systems is that they start with a quick approximation, then iterate as time permits. at any time there is a useable output. the more time available, the better. there's probably a definition that uses the notion of continuity - for every error epsilon, there's a time delta. maybe uniform continuity - for every epsilon at any time, there's a constant time delta. i agree that the best definition of "real-time" programs is programs that are written with explicit attention to timing.
low@melair.UUCP (Rick Low) (03/03/90)
To quote Isaac Wong's posting here last October: From the IEEE Standard Dictionary of Electrical and Electronics Terms Real Time (1) (general) (A) Pertaining to the actual time during which a physical process transpires. (B) Pertaining to the performance of a computation during the actual time that the related physical process transpires in order that results of the computation can be used in guiding the physical process. (2)................ Can we move on now? -- Rick Low MEL Defence Systems Limited, Ottawa, Canada +1 613 836 6860 mitel!melair!low@uunet.UU.NET
rlk@telesoft.com (Bob Kitzberger @sation) (03/03/90)
In article <1556@mcrware.UUCP>, ylee@mcrware.UUCP (Yeongleh Lee) writes: > > So one characteristic of real time system is "Priority-based preemptive > scheduling of tasks to ensure that the task of highest priority is executed > when it becomes runnable". A nit... these are characteristics of the tools used to implement a real-time system, not the real-time system itself. > Another characteristics of real time system is "Direct control of the > scheduler by user processes to guarantee the execution of the appropriate > task". For the Cyclic Executive model of real-time design, sure. Other approaches such as Rate Monotonic Scheduling are elegant solutions to deadline scheduling, but mucking with the scheduler may invalidate RMS scheduling performed by your runtime system or kernel. So again, the need for this depends on the tool chosen to implement a real-time system. Just trying to separate specification from implementation here... .Bob. p.s. by the way, I agree with the poster that suggested someone put together a "what is a realtime system?" answer pack for monthly posting ;-) -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Ct. West at&t : (619) 457-2700 x163 San Diego, CA 92121-9891 "Dawn : The time when men of reason go to bed." ------------------------------------------------------------------------------
rlk@telesoft.com (Bob Kitzberger @sation) (03/03/90)
> The only reason that I can see for not considering the payroll system > (or your nervous system for that matter) a "real time" system is > hidebound thinking -- if it ain't exclusively chips and wires, it ain't > a System. "soft" realtime : half-baked systems "hard" realtime : difficult to develop "easy" realtime : payroll systems Oh yeah... ;-) .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Ct. West at&t : (619) 457-2700 x163 San Diego, CA 92121-9891 "Dawn : The time when men of reason go to bed." ------------------------------------------------------------------------------