ntpd failing to reach PPS input
by hamsterpoop from LinuxQuestions.org on (#5PKT3)
Hi there.
I am running a NTP server on a BeagleBone Black, it gets its time from a GPS receiver through NMEA and PPS. I am currently experiencing that ntpd fails to get the PPS input most of the time:
Code:debian@beaglebone:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS-. 0 l 9 16 377 0.000 -148.66 2.373
PPS(0) .PPS. 0 l 157 8 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 10 l 155 64 4 0.000 0.000 0.002It will, seemingly randomly, suddenly reach the PPS for several minutes before loosing it again for several minutes. Like here:
Code:
debian@beaglebone:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS-. 0 l 5 16 377 0.000 1.972 5.258
oPPS(0) .PPS. 0 l 3 8 377 0.000 136.903 0.855
LOCAL(0) .LOCL. 10 l 276 64 20 0.000 0.000 0.002When PPS is reached ntpd slowely adjusts the systemtime such that the PPS offset gets smaller. (around 0.1ms in one poll interval)
I am verifying that the kernel infact is picking up a regular PPS signal by:
Code:debian@beaglebone:~$ sudo 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 1631783918.856865052, sequence: 8026 - clear 0.000000000, sequence: 0
source 0 - assert 1631783919.856887269, sequence: 8027 - clear 0.000000000, sequence: 0
source 0 - assert 1631783920.856907653, sequence: 8028 - clear 0.000000000, sequence: 0
source 0 - assert 1631783921.856935578, sequence: 8029 - clear 0.000000000, sequence: 0
source 0 - assert 1631783922.856959128, sequence: 8030 - clear 0.000000000, sequence: 0
^C
Any ideas for how I can debug this?
This is the config file
Code:debian@beaglebone:~$ cat /etc/ntp.conf
# Date: November 3 2020
# Purpose: This is the config file for ntpd using gpsd with a ublox zed-f9p as GPS source
# Log stuff
#statistics loopstats peerstats clockstats sysstats
statistics peerstats
filegen peerstats file peerstats type day enable
logfile /var/log/ntp.log
statsdir /var/log/ntpstats/
# Guard against DDOS
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 10.0.60.0 mask 255.255.255.0 nomodify notrap # Allows machines on 10.0.60.0 -> 10.0.60.255 to request timing from us
restrict -6 ::1
restrict 127.0.0.1 mask 255.255.255.0
tos mindist 0.300
# GPS Shared Memory Clock from GPSD
# NMEA refclock driver directly from serial port
server 127.127.20.0 mode 56 minpoll 4 iburst prefer true
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.00 refid GPS-NMEA
# GPS: PPS/ATOM from pps-gpio service
server 127.127.22.0 maxpoll 3 minpoll 5 iburst
fudge 127.127.22.0 refid PPS time1 0.000001
fudge 127.127.22.0 flag3 1
# Add backup based on own system clock
server 127.127.1.0
fudge 127.127.1.0 stratum 10
I am running a NTP server on a BeagleBone Black, it gets its time from a GPS receiver through NMEA and PPS. I am currently experiencing that ntpd fails to get the PPS input most of the time:
Code:debian@beaglebone:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS-. 0 l 9 16 377 0.000 -148.66 2.373
PPS(0) .PPS. 0 l 157 8 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 10 l 155 64 4 0.000 0.000 0.002It will, seemingly randomly, suddenly reach the PPS for several minutes before loosing it again for several minutes. Like here:
Code:
debian@beaglebone:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(0) .GPS-. 0 l 5 16 377 0.000 1.972 5.258
oPPS(0) .PPS. 0 l 3 8 377 0.000 136.903 0.855
LOCAL(0) .LOCL. 10 l 276 64 20 0.000 0.000 0.002When PPS is reached ntpd slowely adjusts the systemtime such that the PPS offset gets smaller. (around 0.1ms in one poll interval)
I am verifying that the kernel infact is picking up a regular PPS signal by:
Code:debian@beaglebone:~$ sudo 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 1631783918.856865052, sequence: 8026 - clear 0.000000000, sequence: 0
source 0 - assert 1631783919.856887269, sequence: 8027 - clear 0.000000000, sequence: 0
source 0 - assert 1631783920.856907653, sequence: 8028 - clear 0.000000000, sequence: 0
source 0 - assert 1631783921.856935578, sequence: 8029 - clear 0.000000000, sequence: 0
source 0 - assert 1631783922.856959128, sequence: 8030 - clear 0.000000000, sequence: 0
^C
Any ideas for how I can debug this?
This is the config file
Code:debian@beaglebone:~$ cat /etc/ntp.conf
# Date: November 3 2020
# Purpose: This is the config file for ntpd using gpsd with a ublox zed-f9p as GPS source
# Log stuff
#statistics loopstats peerstats clockstats sysstats
statistics peerstats
filegen peerstats file peerstats type day enable
logfile /var/log/ntp.log
statsdir /var/log/ntpstats/
# Guard against DDOS
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 10.0.60.0 mask 255.255.255.0 nomodify notrap # Allows machines on 10.0.60.0 -> 10.0.60.255 to request timing from us
restrict -6 ::1
restrict 127.0.0.1 mask 255.255.255.0
tos mindist 0.300
# GPS Shared Memory Clock from GPSD
# NMEA refclock driver directly from serial port
server 127.127.20.0 mode 56 minpoll 4 iburst prefer true
fudge 127.127.20.0 flag1 0 flag2 0 flag3 0 flag4 0 time1 0.00 refid GPS-NMEA
# GPS: PPS/ATOM from pps-gpio service
server 127.127.22.0 maxpoll 3 minpoll 5 iburst
fudge 127.127.22.0 refid PPS time1 0.000001
fudge 127.127.22.0 flag3 1
# Add backup based on own system clock
server 127.127.1.0
fudge 127.127.1.0 stratum 10