Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!spdcc!merk!alliant!linus!chance!munck
From: munck@chance.uucp (Robert Munck)
Newsgroups: comp.realtime
Subject: Re: What makes a system "real-time?" (Was: Real-Time references wanted)
Message-ID: <74633@linus.UUCP>
Date: 19 Oct 89 13:16:52 GMT
References: <1989Oct18.151758.5227@planck.uucp>
Sender: news@linus.UUCP
Reply-To: munck@chance.UUCP (Robert Munck)
Organization: MITRE-McLean Software Engineering Laboratory
Lines: 29

In article <1989Oct18.151758.5227@planck.uucp> westley@avenger.UUCP (Terry J. Westley) writes:
>	A system is real-time when the result of some
>	operation is wrong because it is late.
>

That's an elegant definition!  Short, understandable, and exactly on
the point.  I expect I'll be quoting it from now on.

>... Some people use the term "hard real-time" to distinguish between systems.

An obvious metric would be the maximum rate at which work must be done
to meet the basic definition.  For example, the ratio between the time
period from the stimulus to the time the result would be late to
the number of lines of code that must be executed in that period.
A given system would have many such ratios for different operations,
so we could characterise the "real-timeness" by the highest of them.

I know, there are problems with this.  The "lines of code executed"
measure is a problem because a poorly-coded system would have a
higher number here.  I really want an absolute measure of the amount
of work to be done in the period, but don't know a better way to
quantify it.  Also, the definition of "late" will have varing degrees
of "softness" before the operation is absolutely "wrong."

These are all minor technical matters to be worked out in particular
cases.  The definition is great!
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688