gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Draft Time Service HOWTO is beginning to approach final f


From: Harlan Stenn
Subject: Re: [gpsd-dev] Draft Time Service HOWTO is beginning to approach final form
Date: Thu, 24 Oct 2013 01:39:38 +0000

Andy Walls writes:
> On Wed, 2013-10-23 at 17:04 -0400, Eric S. Raymond wrote:
> 
> > Some minor issues from the draft:
> > 
> > TODO: There's an open issue about how you know you're stabilized
> > enough to compute a correct offset.
> > 
> > This is an issue for both nptd and chrony.  Is it sufficient to say,
> > for a GPS, that we need to wait until (a) we are sure the device has 
> > been powered up and has skyview long enough to download an ephemeris,
> > and (b) it's been getting continuous fixes for a few minutes?  Or are
> > there other considerations involved?
> 
> Off the cuff:
> 
> 1. ntpd has a built in hold timer at startup before it does any grooming
> of the clock.  It defaults to 300 seconds:
> http://www.eecis.udel.edu/~mills/ntp/html/clock.html
> http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#tinker
> That's a nice hard minimum time to wait for the HOWTO.

That's a choice if one is only looking to sync with a local refclock
that may be in cold-start.

What would be better is to use this as a means to motivate GPS and other
refclock vendors to do a better job reporting "state" - precision,
error, etc.

If one has a good drift file and the upstreams are in good shape, ntpd
can do a restart and  achieve full sync in about 11 seconds' time.

But since most folks here are keenly aware of the differences between
mechanism and policy I'm not particularly concerned.

> 2. I have recollections from past projects, that ntpd would take up to
> 15-20 minutes after start-up to step a system clock that was a few
> seconds (~1.5 seconds IIRC) off.  If you don't allow ntpd to step the
> system clock and force ntpd to always slew it, correcting a second by
> slewing takes about an ?hour? (my memory is *very* fuzzy here).

500ppm.  As I recall, the default step threshold is 128ms so if there is
a 128ms correction to be made this will take 256 seconds to apply, or
just over 4 minutes.  For some reason I remember there is some other
thing going on, and in the case where there is a "large" offset to be
slewed it will not apply before the 15 minute(?) something completes,
which can cause a wobble.

> 3. One needs to check if ntpd has labeled *anything* a falseticker using
> the ntp tools.  Falsetiker declarations usually happen early (except see
> WARNING below).  ntpd can still report stats on falsetickers, but one
> needs to figure out what ntpd doesn't like about it, if it is a
> refclock.
> 
> WARNING: In the case of a GPS unit that inserts an unannounced second
> due to downloading an updated GPS-UTC leap-seconds correction from the
> GPS almanac after start-up, the falseticker declaration for the GPS unit
> will happen some time less than 12.5 minutes (IIRC) after startup.  I
> have had two ntpd configs trying to deal with this sort of thing and
> both failed to work properly.  One config caused ntpd to declare the GPS
> unit a flaseticker forever,  The other ntpd config accepted the step
> from the GPS unit, but ntpd took an ?hour? (my memory is fuzzy here) to
> slew the clock to the GPS time.

How can we set up test cases for this?

H



reply via email to

[Prev in Thread] Current Thread [Next in Thread]