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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
