Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!brutus.cs.uiuc.edu!ginosko!uunet!rosevax!bert.Rosemount.COM!bill
From: bill@bert.Rosemount.COM (William M. Hawkins)
Newsgroups: comp.realtime
Subject: Re: def. real time
Summary: Other kinds of time
Message-ID: <8214@rosevax.Rosemount.COM>
Date: 26 Oct 89 04:53:11 GMT
References: <5417@eos.UUCP>
Sender: news@rosevax.Rosemount.COM
Reply-To: bill@bert.Rosemount.COM (William M. Hawkins)
Distribution: na
Organization: Rosemount Inc., Burnsville, MN
Lines: 27

In article <5417@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>When you guys get around to defining real-time (I like and know the
>requirements of the Nevada Test Site example), can one of you set up
>a Unix system with crontab posting a once a month frequently asked
>question file?

OK, gene, what are the requirements of the Nevada atomic site?
I've not seen them go by, so perhaps they should be added to the
canonical list of real time definitions.

Nobody so far has tried to define real time in terms of what it
is not:

Negative time - when it absolutely, positively has to be there
   yesterday.

Imaginary time - please rotate your sensors ninety degrees in
   order to restore reality.

But seriously, real time computing can also mean that a set of
distributed (networked) processors all have the same definition
of time of day, within some uncertainty tolerance.  What is that
tolerance on a network?  Can it be reduced by using half the time
for a request - response transaction as the "lead" time for a
time of day message?

bill@bert.rosemount.com