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 X-Google-Attributes: gidf569d,public X-Google-Thread: 1108a1,9292211c2d4756a8 X-Google-Attributes: gid1108a1,public X-Google-Thread: 102b75,7d68662d79c59f1c X-Google-Attributes: gid102b75,public X-Google-Thread: 109fba,46882e3fad98420e X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7d68662d79c59f1c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-12-31 21:25:21 PST Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!pipex!uunet!dove.nist.gov!news-reader.nist.gov!przemek From: przemek@rrdjazz.nist.gov (Przemek Klosowski) Newsgroups: comp.lang.c++,comp.object,comp.arch,comp.multimedia,comp.lang.ada Subject: Re: What's Real-Time? (was Re: Widespread C++ Competency Gap?) Date: 31 Dec 1994 17:08:19 GMT Organization: U. of Maryland/NIST Message-ID: 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> NNTP-Posting-Host: rrdjazz.nist.gov In-reply-to: hbaker@netcom.com's message of Sat, 31 Dec 1994 01:09:13 GMT Xref: nntp.gmd.de comp.lang.c++:84681 comp.object:19069 comp.arch:27401 comp.multimedia:25709 comp.lang.ada:17722 Date: 1994-12-31T17:08:19+00:00 List-Id: In article hbaker@netcom.com (Henry Baker) writes: In article <3e26mc$n9u@Starbase.NeoSoft.COM>, dweller@Starbase.NeoSoft.COM (David Weller) wrote: > 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? 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. ... 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! :-) :-) There is an interesting article in latest issue of Dr. Dobbs, written by the real time honcho at DEC. He claims that 'hard real time' is basically impossible for most complicated systems (he had an interesting insight that often people start with 'hard' systems, put them in a distributed environment and end up with 'soft' system because of communication issues: 'hard real time' being just a self-delusion in that case). The article claims that for large systems the average resource requirements are vastly different from worst-case requirements, and so large 'hard' systems in the traditional sense are simply too wasteful. An example is the telephone system. It is not 'hard real time': the cost would be just too big. Instead, they figured out how to manage available resources to have acceptably low failure rates. -- przemek klosowski (przemek@rrdstrad.nist.gov) Reactor Division (bldg. 235), E111 National Institute of Standards and Technology Gaithersburg, MD 20899, USA (301) 975 6249