eugene@eos.UUCP (Eugene Miya) (10/25/89)
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?
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"You trust the `reply' command with all those different mailers out there?"
"If my mail does not reach you, please accept my apology."
{ncar,decwrl,hplabs,uunet}!ames!eugene
Support the Free Software Foundation (FSF)bill@bert.Rosemount.COM (William M. Hawkins) (10/26/89)
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
madd@world.std.com (jim frost) (10/26/89)
In article <8214@rosevax.Rosemount.COM> bill@bert.Rosemount.COM (William M. Hawkins) writes: |Negative time - when it absolutely, positively has to be there | yesterday. This can be accomplished in a bureaucracy throught the proper use of rubber date stamps on documentation. Perhaps we should call this surreal time :-). jim frost software tool & die madd@std.com
stein@dhw68k.cts.com (Rick 'Transputer' Stein) (10/28/89)
In article <8214@rosevax.Rosemount.COM> bill@bert.Rosemount.COM (William M. Hawkins) writes: >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? This idea sounds like something I term "Local Area Multicomputer Time (LAMT)." LAMT is constructed by synchronizing the clock phases on each node in the multicomputer with a standard reference (A Cesium clock if need be). Suppose you've got a multicomputer systems built up out of my favorite iron: Inmos Txxx. One of those nodes must be hosted by a workstation of some other server. So, take the time returned from a "gettimeofday" system call, and broadcast that value to all nodes in the network, adding an offset value to the timestamp proportional the to route time between hops. When the time is loaded, you've got a local area mulitcomputer with each node keeping the identical time as all the rest. Simple no??? The tolerance for LAMT is dependent on your simulation requirements. Meaning that if you have processes requiring time keeping to 10 usecs, then you better make damn sure that your clocks in each node count by shorter intervals, and that they don't drift. >bill@bert.rosemount.com -- Richard M. Stein (aka, Rick 'Transputer' Stein) Sole proprietor of Rick's Software Toxic Waste Dump and Kitty Litter Co. "You build 'em, we bury 'em." uucp: ...{spsd, zardoz, felix}!dhw68k!stein