3

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
Michael Graff
  • 6,588
  • 1
  • 23
  • 36
  • It should not be a stratum 0, the first is 1, no ? – Dom Jan 31 '16 at 08:56
  • Stratum 0 is a directly connected time source. In this case, a PPS clock can act as a time source, given that the approximate second is transmitted using other means. In this case, I'm using GPS and/or other network servers. Once those are sync'd, PPS would provide a stratum 0 source, and is correct. – Michael Graff Jan 31 '16 at 09:00
  • I'm having this exact issue, except with driver 20 (Generic NMEA) and 22. I can get driver 20 to work fine on its own, but when I add driver 22 as well, I get the falsetick failure. I think the falsetick is between the two drivers and I'm not sure how to resolve it. – lightswitch05 Jan 16 '20 at 03:47

1 Answers1

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.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • I can understand why some devices are rejected, but what I thought the PPS driver did was further optimize the time, once sync'd. That is, the rough time is set by a preferred source, but once set, the PPS will mark the actual second change, and from that point onward PPS will be used. This seems not to be the case. – Michael Graff Feb 03 '16 at 07:52