Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!luth!sunic!mcsun!ukc!stl!neon!xstuart!huw
From: huw@xstuart.siesoft.co.uk (Huw Roberts)
Newsgroups: comp.realtime
Subject: Re^2: What is "real-time" really?
Message-ID: <1815@neon.siesoft.co.uk>
Date: 16 Mar 90 08:12:52 GMT
References: <98692@linus.UUCP> <1990Feb24.195542.21454@newcastle.ac.uk> <98987@linus.UUCP> <8178@pt.cs.cmu.edu>
Sender: news@neon.siesoft.co.uk
Lines: 60


I once heard a fairly glib but thought provoking definition of a real-time
system which I believe summarizes the concept nicely  (Please excuse any
spelling mistakes as I've got some sort of viral infection :-) ).

David Stewart comes very close with his statements but he misses the fact that
this is the defining point of a real-time-system:

>.....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.

My (well, actually paraphrased from Yan Wong of STC's) definition of a
Real-Time-System is:
"One in which the functional constraints are such that they compell the
implementors of the system to ensure that the system hardware is ALWAYS
underutilised".

In other words, the CPU must never hit 100%, the disks (if any) must never
thrash and there will always be memory bandwidth available.

So, the payroll example cannot be a Real-Time-System because the machine is
allowed to be fully utilised towards the end of the month.  In addition,
a system with real-time elements may not be a complete real-time-system
because the implementors are (for example) using up waste cycles to calculate
mandlebrot sets.  A multiplexor IS a real-time-system because if the CPU
usage ever hit 100% and a new message arrived, then some of the data is lost
and the system fails to meet its requirements.  The implementors are
constrained to ensure that the system is underutilised.

Huw

Flame me please!  (Although turn around may well be a month).
-------------------------------------------------------------------------------
Name  Huw Roberts                   Siemens Plc., System Development Group,
Mail. huw@siesoft.co.uk             Woodley House, 65-73, Crockhamwell Road,
Tel.  +44 734 443068                Woodley, Reading,
Fax.  +44 734 698874                Berkshire, RG5 3JP  England.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Name  Huw Roberts                   Siemens Plc., System Development Group,
Mail. huw@siesoft.co.uk             Woodley House, 65-73, Crockhamwell Road,
Tel.  +44 734 443068                Woodley, Reading,
Fax.  +44 734 698874                Berkshire, RG5 3JP  England.
-------------------------------------------------------------------------------