[FoRK] re RT, precision, distance, etc.
jbone at place.org
Thu Dec 24 06:41:32 PST 2009
> 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
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-
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.)
More information about the FoRK