[FoRK] re RT, precision, distance, etc.

Jeff Bone jbone at place.org
Thu Dec 24 06:41:32 PST 2009


Ken says:

> I'm good with that. As long as "earliest-possible" isn't measured in  
> minutes or days or months.

It's not in the areas I'm involved in these days, of course.  But in  
the limit, what do you measure?  In a very-long-haul DTN network, say  
between Earth and a spacecraft heading out of the solar system, the  
time (distance) between our perception of an originating event here  
and the arrival of that event at the spacecraft is at the low end of  
the range;  when we use (meaningful, I assert) words like RT in this  
kind of context, the time we're really talking about is the time  
between the arrival of that event at the destination and the earliest- 
possible time that userspace software on the spacecraft (as opposed to  
hardware / system software) can react to it.  In that case, RT's  
probably more a factor in relating to local events than remote ones.   
But I can't imagine a hardware / software stack in which the inherent  
system-imposed delay between first arrival of some external event and  
userspace code becoming aware of it, and being able to handle it,  
being more than micro- or nanoseconds these days. More to the point,  
though, RT also implies that the userspace code should be able to  
*complete* its handling of the event without being preempted or  
interfered with by other, lower-priority, system- or userspace code.   
(So there's your relatively rigorous definition of what I (and lots of  
folks working under similar constraints) mean by RT;  FWIW, hasn't  
changed much since the late 80s, cf. Wind River, QNX, Posix 4, etc.

In my domain these days, the most-distant events of interest tend to  
originate milliseconds away, but the ability to react to them within  
micro- / nano- seconds of their arrival is highly important.

> If it's date/time-stamping, it should be so close to the "actual"  
> time that most users will be okay with weasel-words like near- 
> realtime. This will generally be sub-second. How much "sub-" will  
> depend on the nature of the events and why anyone cares about "when"  
> they occured.

So this isn't so much about "RT" as it is about accuracy and precision  
when trying to paint a causal picture of inherently acausal phenomena.

Your definition inherently elevates concerns of human perception  
higher than they should be these days, for the systems of interest  
that I'm talking about;  you're assuming things that aren't  
necessarily true about large, interesting classes of software (like  
the kind I deal with.)  The (human) user generally doesn't get  
involved in these and other automated, optimal-control type problems  
until after the fact;  the events in question to which systems react  
are generated by other systems and / or physical or other real-world  
phenomena, and the nature of the game is often to be first to react.   
Outcomes can ride on whether one is fast enough, accurate enough,  
precise enough, and can deal with the fuzzy nature of when  
something(s) "actually" occurred.
In the limit, it's impossible to determine the "actual" time of  
something occurring (cf. Einstein.)  Particularly when the gig is to  
understand and react to some ordering of events originating at  
different sources, communicated to you over different channels of  
different light-length and with different and variable delays, this  
gets tricky.  The ability to do this "better" than others is of  
Darwinian importance in certain areas....
(These kinds of errors / sensory imprecision and inaccuracy, and the  
systems that deal with them, are the subject of an entire field of  
study originating in aerospace systems research but applicable  
elsewehere.  Cf. "optimal control theory."  It's an interesting  
problem in e.g. spacecraft control, but broadly applicable elsewhere.)

Here's a homework question for you, Ken.  What's the difference  
between "accuracy" and "precision?"

> As you mentioned, this is getting more and more "sub-" all the time.  
> The question is, is "micro-" or "nano-" really necessary?

Absolutely.  The machines care, and in this case that means I  
care. ;-)  Any time you get an ecosystem of machines going in which  
events are being generated by and reacted to by machines, without a  
"user" anywhere in the data path, these concerns will become  
criticial.  Particularly when there's money on the line.  (Similar  
comments apply when some of the events are representations of physical  
phenomena.)

re zipdist, Bill K. asks:

> What defines distance here? A straight line, as the crow flies? Or  
> over-the-roads? Makes quite a difference when local terrain gets in  
> the way...

Excellent question.  In fact, since a zipcode is an area rather than a  
point, there are two interesting issues here.  Even if you assume  
Euclidian distance between zipcodes, there do you put the ends of the  
measuring line?  Closest two points in the two regions?  Most  
distant?  Mean of the two?  Mean of the distances between all pairs of  
points drawn one from each region?  Some kind of geometric center-to- 
center?

In this case, I was one of those woefully inaccurate human users that  
Ken is fixated on, and the answers to the above didn't really matter  
as the potential margin of error given any particular definition of  
distance between zips was uninteresting regardless of how this was  
calculated, as long as the calculation was "reasonable."  I assumed  
geocoder's calculation method was reasonable.  I.e., I don't actually  
know what geocoder is calculating but it didn't matter for my  
particular purpose at that point.  (Basically, I needed a quick filter  
to screen out potential nannies --- based on profiles scraped from a  
web site --- that lived "more than x miles away."  In this case, the  
margin of error was such that it didn't really impact the outcome.)

$0.02,

jb




More information about the FoRK mailing list