From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f569d,7d68662d79c59f1c,start X-Google-Attributes: gidf569d,public X-Google-Thread: 109fba,46882e3fad98420e X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7d68662d79c59f1c,start X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9292211c2d4756a8 X-Google-Attributes: gid1108a1,public X-Google-Thread: 102b75,7d68662d79c59f1c,start X-Google-Attributes: gid102b75,public X-Google-ArrivalTime: 1994-12-31 07:26:55 PST Newsgroups: comp.lang.c++,comp.object,comp.arch,comp.multimedia,comp.lang.ada Path: nntp.gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!NewsWatcher!user From: hbaker@netcom.com (Henry Baker) Subject: Re: What's Real-Time? (was Re: Widespread C++ Competency Gap?) Message-ID: Sender: hbaker@netcom.com (Henry G. Baker) Organization: nil References: <787227087snz@wslint.demon.co.uk> <3da1nd$fss@gateway.wiltel.com> <3e1rqn$ouh@news.parc.xerox.com> <3e22hi$pqf@baygull.rtd.com> <3e26mc$n9u@Starbase.NeoSoft.COM> Date: Sat, 31 Dec 1994 01:09:13 GMT Xref: nntp.gmd.de comp.lang.c++:84605 comp.object:19057 comp.arch:27391 comp.multimedia:25687 comp.lang.ada:17712 Date: 1994-12-31T01:09:13+00:00 List-Id: In article <3e26mc$n9u@Starbase.NeoSoft.COM>, dweller@Starbase.NeoSoft.COM (David Weller) wrote: > In article <3e22hi$pqf@baygull.rtd.com>, Don Yuniskis wrote: > >In article <3e1rqn$ouh@news.parc.xerox.com>, > >Hans Boehm wrote: > >>I'm not an expert on real-time programming. But I'm always confused > >>by these discussions. It seems to me that "real-time" is usually > >>intended to mean one of the following two extremes, or anything > >>in between: > >>1. Reasonable interactive response on a fast machine. Maybe good enough > >>so that a video game isn't too jerky. > >>2. Part of a safety critical system that requires millisecond or so > >>GUARANTEED response, and GUARANTEED space bounds. > > > >Actually, neither is really correct. Typically real-time == real-fast. > >However, real-fast != real-time. Also, real-time !-> real-fast > > This is contrary to any text I've read. Maybe I just live in a > closet? :-) Can you cite a "Real-Time" text or two that says this? > > I've always learned "Real-Time" as implying determinism. Of course, > I may have a narrow view because I write space and flight simulators > :-) > > A rate of 1Hz is _definitely_ real-time, PROVIDED you neither exceed > or fall below that rate. Cxu vi komprenas ke mi diras? In the RT community there are the terms '_hard_ real-time' and '_soft_ real-time'. 'Hard' RT means that the consequences of missing a deadline are catastrophic, while 'soft' RT means that the consequences are expensive, but not catastrophic. Designing for a 'hard' RT system is different from designing for a 'soft' RT system because you have to find the latencies of _every_ operation, no matter how rare -- e.g., you have to worry about the latencies of rare combinations of rare events -- e.g., multiple page faults from a single instruction, cache faults for every memory reference of a 1000-instruction sequence, etc. Unfortunately, nearly _all_ of the progress in HW performance in the last 20 years has been in _mean_ performance, _not_ worst-case performance. In fact, worst-case performance has only improved modestly over this period. The _ratio_ of mean to worst-case performance has increased dramatically, so that it may be 100:1 or more today. This means that nearly everyone is looking for ways to convert 'hard' RT systems into 'soft' RT systems so that they can take advantage of the increased average speeds. So if you're still doin' 'hard time', wise up! :-) :-)