I am attempting to add a GPS-based clock source to my network, using a GPS which emits a 1-PPS clock pulse. This is connected to a GPIO pin.
After allowing ntpd to run for 30 minutes or so, the PPS clock is still not used, and marked as bad, but I cannot figure out why.
ntpq> opeer
remote local st t when poll reach delay offset disp
==============================================================================
-127.127.28.0 127.0.0.1 2 l 5 16 377 0.000 17.704 2.125
x127.127.22.0 127.0.0.1 0 l 4 16 377 0.000 6.546 0.260
+50.116.36.122 10.42.134.1 3 u 33 64 377 43.017 2.337 5.208
+52.0.56.137 10.42.134.1 3 u 33 64 377 52.022 -6.430 3.944
-2001:418:8405:4 _d58f:78d0:fd39 3 u 30 64 377 85.262 13.465 4.929
*104.156.99.30 10.42.134.1 2 u 32 64 377 63.671 -0.166 5.484
ntpq> assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 2139 933a yes yes none outlier sys_peer 3
2 2140 9134 yes yes none falsetick reachable 3
3 2141 9424 yes yes none candidate reachable 2
4 2142 9424 yes yes none candidate reachable 2
5 2143 9324 yes yes none outlier reachable 2
6 2144 963a yes yes none sys.peer sys_peer 3
ntpq> rv 2140
associd=2140 status=9134 conf, reach, sel_falsetick, 3 events, reachable,
srcadr=127.127.22.0, srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
stratum=0, precision=-20, rootdelay=0.000, rootdisp=0.000, refid=PPS,
reftime=da584969.00b5c330 Sun, Jan 31 2016 8:50:49.002,
rec=da584969.0f2551bb Sun, Jan 31 2016 8:50:49.059, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=4, headway=0, flash=00 ok,
keyid=0, ttl=0, offset=9.551, delay=0.000, dispersion=0.260,
jitter=2.148,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= 9.55 9.97 10.46 10.98 11.49 11.95 12.46 12.91,
filtdisp= 0.03 0.27 0.51 0.75 0.99 1.23 1.47 1.71
The PPS source itself appears to be very clean and regular:
# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1454230928.995087804, sequence: 7552 - clear 0.000000000, sequence: 0
source 0 - assert 1454230929.995115719, sequence: 7553 - clear 0.000000000, sequence: 0
source 0 - assert 1454230930.995144056, sequence: 7554 - clear 0.000000000, sequence: 0
source 0 - assert 1454230931.995173388, sequence: 7555 - clear 0.000000000, sequence: 0
source 0 - assert 1454230932.995202464, sequence: 7556 - clear 0.000000000, sequence: 0
source 0 - assert 1454230933.995230660, sequence: 7557 - clear 0.000000000, sequence: 0
source 0 - assert 1454230934.995258966, sequence: 7558 - clear 0.000000000, sequence: 0
source 0 - assert 1454230935.995287693, sequence: 7559 - clear 0.000000000, sequence: 0
source 0 - assert 1454230936.995317675, sequence: 7560 - clear 0.000000000, sequence: 0
source 0 - assert 1454230937.995345684, sequence: 7561 - clear 0.000000000, sequence: 0
source 0 - assert 1454230938.995375052, sequence: 7562 - clear 0.000000000, sequence: 0
source 0 - assert 1454230939.995403851, sequence: 7563 - clear 0.000000000, sequence: 0
source 0 - assert 1454230940.995433228, sequence: 7564 - clear 0.000000000, sequence: 0
source 0 - assert 1454230941.995463497, sequence: 7565 - clear 0.000000000, sequence: 0
source 0 - assert 1454230942.995491843, sequence: 7566 - clear 0.000000000, sequence: 0
2140 was discarded as a falseticker, it wasn't in the interval chosen by the clock select algorithm. The error intervals lined up such that the candidates selected did not include it. As more than half of the candidates remain the clock is considered correct.
There is a prefer keyword for peers although it looks to apply after discarding falsetickers.
Consider using ntpdate on a peer that seems to perform well and restart ntpd with different peers for a second opinion. If it prefers network peers and they are relatively low delay and jitter that isn't too bad.