[time-nuts] OT: NTP server questions

Wed Dec 1 14:37:15 UTC 2010

On Wed, Dec 1, 2010 at 12:58 AM, <scmcgrath at gmail.com> wrote:

> I think we are getting precision and accuracy confused,
>
>
Perhaps, but it's not me!

> And they are quite different,   In the time-nut world we use them as
> synonyms, In reality its possible to have a precise measurement which is not
> accurate (think instrument with bad timebase it's repeatable and reads out
> to a high degree of precision but it's INACCURATE).
>
>  We can also  have a accurate measurement in with resolution in gross units
> like minutes or seconds but be highly ACCURATE but have a low degree of
> PRECISION.
>
> What's needed is ACCURATE time referenced to a external standard to within
> milliseconds with a resolution of 1 second as application does not
> understand any unit smaller than 1 second.
>
>
What's needed is for the clocks to be in agreement with each other but
accuracy doesn't matter when it comes to how close they come to UTC time.
They could all be 3 hours off but as long as they all agree with each other
to a precision of one second, then everything we care about will work.

-Bob

> Scott
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Robert Darlington <rdarlington at gmail.com>
> Sender: time-nuts-bounces at febo.com
> Date: Wed, 1 Dec 2010 00:34:00
> To: Discussion of precise time and frequency measurement<
> time-nuts at febo.com>
> Reply-To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Subject: Re: [time-nuts] OT: NTP server questions
>
> 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.
> >
> _______________________________________________
> 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.
> _______________________________________________
> 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.
>