[time-nuts] OT: NTP server questions

[Robert Darlington]

There are sometimes delays up to 30 minutes or so due to processing of
sensor data till it makes it into my system which is also way out in the
field.  Imagine a shipping pallet full of equipment that gets air dropped
into the middle of nowhere.  That IS my network, and it has no connection to
anything but the sensors deployed with it.  Maybe on a good day I'll have a
wireless or satellite connection back to another network that may or may not
have a time server on it.   I can't ever assume this will be the case.  I
will, however, be rotating hard disks full of collected sensor data for
off-line analysis (forensic stuff) at a less remote location.  I will have
spare parts (including NTP servers) at this location that will be visited
daily.

I really only need time to one second.  Most file systems don't have any
finer granularity and we're not making scientific measurements.   We have a
system to display transient events inside of a time window that can be
arbitrarily set, but typically no wider than 15 minutes.  If the data is 15
minutes old, it's not important anymore.  If the data is 40,000 years in the
future due to a bad time stamp like when it's marked in miliseconds since
the epoch (unix time) instead of seconds, we won't ever see it since it too
is outside of my window.  If it's 4 seconds old, that's okay.  I'll see it
inside of my time window.

The problem with arrival times is that things I'm looking for don't happen
the instant I get alerted.  I may want to go back and look at when events
happened and compare that with when I was notified so I can see where the
bottle necks are.  If I have a 5 second delay and 5 seconds of clock drift
in the same direction, I don't see any bottleneck which is why I need to
know roughly what time it is at each sensor, computer, and server at least
to one second.  It's rare when something I'm looking for comes directly into
one of my systems.  Almost always there is some processing going on by other
teams on the project that are working independently from my team trying to
make use of some of the data in different ways.  They would then generate
the alert message into my system.  One of these teams that created data used
a TAI reference clock and the folks using this  data used UTC (as do I) and
it really caused problems since one set of sensors is saying some event
happened at a particular time and yet, there was nothing there at that time
according to other sensors.   I think in this case it was cars driving down
a street (I have no idea how they actually determine this since I just
ingest data) and another group took video data to generate tracks for
vehicles that were not there at the time the vehicle detectors said they
were.  34 second delay (TAI vs UTC) means I'm more than a half mile away
from the sensor if I'm going about 60mph.  If I'm trying to predict when a
car will be near another sensor based on bad data, we'll never be looking at
the right time.

-Bob

On Wed, Dec 1, 2010 at 12:08 AM, Hal Murray <hmurray at megapathdsl.net> wrote:

>
> rdarlington at gmail.com said:
> > That's exactly what we've done in the past (setting it when on the
> network
> > and letting the clock do what it wants) and that's fine.  The actual time
> > isn't as important as the agreement on what time it is.  This is
> certainly
> > the cheaper way to go and is becoming a viable option.
>
> How long does it take for data to get from way out in the field to your
> system?
>
> Earlier, you said that you only needed time to within a second.  That's a
> long time for networking.
>
> If it's only 100 ms (pulled out of the air) for the data to get from the
> sensor to your system, then forget all the timestamps as the local system
> and
> just use the arrival time at your system.
>
> If a significant part of the delay is things like RS-232 baud rates, you
> can
> correct for that constant offset.  (or semi-constant if the length of a
> message varies, but maybe you can record the length of the message and do
> the
> right correction)
>
>
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>