[ntp:questions] Re: Server stopped syncing to PPS?

David L. Mills mills at udel.edu
Fri Feb 3 14:54:20 UTC 2006


Peter,

You need to understand how the selection alrogithm works. Each source is 
assigned a correctness interval as a function of roundtrip delay and 
dispersion. The correctness interval is the intersection of these 
intervals. The selection algorithm runs an intricate algorithm to 
determine which sources are inside or outside the intersection of these 
intervals. As the result of j-random wiggles, the PPS might stray 
outside the intersection. You have a fairly large set of sources and 
they do wiggle relatively large. Therefore, the selection algorithm does 
what it can.

If you need very precise time, trim off those sources that are 
destabilizing the algorithm. Alternatively, shim up the padding on the 
correctness interval using the tinker mindist command something more 
than the default 5 milliseconds.

Dave

Peter Eriksson wrote:

> How can one find out *why* a server suddenly decieded that the
> PPS signal should be ignored (even though it looks just fine)
> after having been running fine for a day or so? (It choose the PPS
> source after a little while just as it should behave).
> 
> System: Sun Ultra 5, Solaris 9, NTP 4.2.0a, ARBITER GPS clock
> 
> # /ifm/bin/ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +ntp1.sp.se      .PPS.            1 u   66   64  376   12.803    1.646   3.563
> +ntp2.sp.se      .PPS.            1 u   45   64  377   15.386    2.901   2.184
> +Time1.Stupi.SE  .PPS.            1 u   57   64  377   11.445    3.674   3.145
> +Time2.Stupi.SE  .PPS.            1 u   21   64  377   10.441    3.154   1.139
> +ntp0-rz.rrze.un .GPS.            1 u   17   64  377   74.422    2.797   2.686
> +ntps1-0.cs.tu-b .PPS.            1 u   70   64  176   75.067    3.061  11.140
> +time.nist.gov   .ACTS.           1 u   50   64  377  157.545    2.023   3.557
> -time-b.nist.gov .ACTS.           1 u   15   64  377  124.831   -6.468   4.648
> +timekeeper.isi. .GPS.            1 u   53   64  177  197.808    3.831   7.902
> +cornelis.lysato 192.36.134.17    2 u   46   64  377    5.733    3.328   3.954
> *GPS_ARBITER(0)  .GPS.            0 l   59   64  376    0.000    0.020   0.022
> -PPS(0)          .PPS.            0 l   24   64  377    0.000    0.053   0.010
> 
> On a related issue - what's the correct procedure to adjust the offset for
> the GPS and PPS signals so that my server will be more in "sync" with
> other NTP servers around the world?
> 
> As you can see from the list I added a number of stratum 1 servers to my
> config in order to try to see what the offset really should be, but it's
> kind of hard to really decided that it should be. And 'time-b.nist.gov'
> seems to be really off a lot of time...
> 
> Another issue that I've seen is that if I unplug the serial cable from
> the GPS and then after a while reinsert the cable it seems like NTPD never
> starts talking to the GPS again. Dunno why though... This is a bit annoying
> (think power outage that temporarily kills the GPS receiver but not the
> server).
> 
> Config file:
> 
> # more /etc/ntp.conf
> enable pps
> 
> server ntp1.sp.se
> server ntp2.sp.se
> 
> server time1.stupi.se
> server time2.stupi.se
> 
> server ntp0.fau.de
> server ntps1-0.cs.tu-berlin.de
> 
> server time.nist.gov
> server time-b.nist.gov
> 
> server timekeeper.isi.edu
> 
> server cornelis.lysator.liu.se
> 
> ### Arbiter GPS clock
> server 127.127.11.0 prefer
> fudge 127.127.11.0 time1 0.02015 
> 
> ### PPS Discipline
> server 127.127.22.0 
> fudge 127.127.22.0 flag3 1
> #fudge 127.127.22.0 time1 0.002
> 
> driftfile /etc/ntp.drift
> 
> statsdir /var/ntp/ntpstats/
> statistics loopstats clockstats 
> filegen loopstats file loopstats type day link enable
> filegen clockstats file clockstats type day link enable
> 
> 
> - Peter
> 




More information about the questions mailing list