[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