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

[Andy Walls]

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.

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).

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.

4. If trying to collect data to calibrate refclocks with unknown
characteristics (i.e. unknown time offset),  the refclock should be
marked with 'noselect', so that is doesn't contribute to ntpd tracking
and discipling of the systems clock.  The exception here is a PPS with
jitter and latency less than what can be measured with the system clock.
A system clock with a 32768 Hz tick with ~30.5 microsecond period, like
with some Linux systems on an OMAP, isn't going to be useful in
calibrating a PPS with a latency of 8 microseconds and a jitter less
than that. 
 
5. One needs to monitor the loopstats for convergence of the system
clock tracking and disciplining.   With a PPS contributing to the
solution, convergence can happen quickly.  You'll certianly want to wait
until the phase jitter and wander (freq jitter) have stopped shrinking
and are fairly constant. One might also want to set criteria on how much
movement one wishes to see in the phase and frequency offsets
themselves.  However, I wouldn't set tight limits on the movement of the
frequency offset, (without a PPS, at least) it can move around a bit,
even if the wander (freq jitter) is reported to be low (due to themral
variations maybe?).

6.  Okay, now when one knows at what timestamp in the loopstats file the
system clock has converged, one can start examining the stability of the
refclocks in the clockstats file starting at that same timestamp.  For
each refclock of interest, one needs to determine at what time the phase
jitter has stopped shrinking and is fairly stable. One might also want
to set criteria on how much movement one wishes to see in the phase
offset.  For an interval when things are stable, once can take an
average of the phase offset for a refclock.  If a PPS refclock, that is
more accurate and precise than the system clock, is *not* contributing
to ntpd's solution for the system clock, then one also needs to take an
average of the PPS refclock's offset from the system clock.  This offset
of the system clock from the PPS, then contributes to the average
offsets computed for the other refclocks from the system clock.


In summary, the time really depends.  Watch for ntpd's jitter estimates
to get small and stay small.

I can't even begin to guess the process by which Gary had machines not
converge after 2 days. :P

Sorry for the novel.

Regards,
Andy