Re: What's Real-Time? (was Re: Widespread C++ Competency Gap?)

[przemek@rrdjazz.nist.gov (Przemek Klosowski)]

In article <hbaker-3012941712040001@192.0.2.1> 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