CODEWITHSUNDEEP
javascriptgpsntpnmea
kshetline
kshetline

Reputation: 13700

I need some help understanding this ntpq output, if it indicates proper GPS sync with PPS

I've created a project (https://github.com/kshetline/aw-clock) that, among many other things, detects GPS time sync with PPS by examining the output from the ntpq command. What I'm expecting is output that looks like this:

pi@clock:~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000   +0.000   0.001
*SHM(2)          .PPS.            0 l    9   64  377    0.000   -0.007   0.001
xSHM(0)          .GPS.            0 l   10   64  377    0.000  -586.75  58.377
-eterna.binary.n 128.138.140.44   2 u   79  128  377   62.565   +2.244   4.420
+t2.time.bf1.yah 98.139.133.62    2 u   53   64  377   28.750   +3.667  10.354
-65-100-46-164.d .SOCK.           1 u    3   64  377   88.300   +3.213   9.568
+time-ewr.0xt.ca 17.253.14.251    2 u   11   64  377   19.489   +2.813  12.572

For my own purposes, checking for the line with both SHM and PPS with the following regex has been working fine for me:

/^\*SHM\b.+\.PPS\.\s+0\s+l\s+.+?\s([-+]?[.\d]+)\s+[.\d]+\s*$/

One of the users of my project says he has GPS sync, but my code isn't detecting it. He's not sure about PPS sync. His output from ntpq looks like this:

pi@raspberrypi:~ $ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001
oPPS(0) .PPS. 0 l 7 16 377 0.000 -290.00 0.321
*SHM(0) .GPS. 1 l 4 16 377 0.000 +4.782 4.952
SHM(2) .SHM2. 0 l - 16 0 0.000 +0.000 0.000
time.skylineser 130.207.244.240 2 u 50 64 1 37.196 -285.61 0.322
+ntp1.ring-u.net 130.207.244.240 2 u 49 64 1 28.878 -280.98 1.622
+50-205-244-108- 50.205.244.27 2 u 47 64 1 27.833 -287.90 3.220
sonic.boom.net 128.9.176.30 2 u 57 64 1 71.871 -284.30 0.001

I can't find sufficient documentation for ntpq to explain how this output works thoroughly enough for me to understand whether this output indicates proper PPS sync, just in a different way than it shows up for me, or if this indicates a problem.

Upvotes: 0

Views: 593

Answers (1)

user3788685
user3788685

Reputation: 3113

The user output is actually the same as yours just without/broken formatting.

It looks like the PPS offset is rather large so I wonder if they have everything configured correctly. They also have an SHM(2) entry which appears to be doing nothing. I wonder if their shared memory config is correct. My input sources list is:

NMEA GPS: xSHM(0) .GPS. 0 l 3 16 377 0.000 -116.89 24.632

PPS: *SHM(1) .PPS. 0 l 6 16 377 0.000 -0.014 0.045

The docs for ntpq can be found here. And the part that explains the status flags can be found here.

Extract from the docs:

  discarded as not valid
x discarded by intersection algorithm
. discarded by table overflow (not used)
- discarded by the cluster algorithm
+ included by the combine algorithm
# backup (more than tos maxclock sources)
* system peer
o PPS peer (when the prefer peer is valid)

I'd be curious to see their actual ntp.conf I wonder if they have an odd or specific setup. At a quick glance I'd say they're actually using the GPS/NMEA as the system peer rather than the PPS. I run several production S1 servers and haven't had a situation where the PPS is marked with an o.

I'm also guessing when they sent you through that output the server had not been running long (or a least not had much connectivity) as the reachability of the remote IP servers is only 2 and given they're polling every 64 sec I'd say they're not reachable or don't like high frequency polls.

Ideally they need to leave it running for a while (at least til everything has a reach of 377) then look again. If they have the full ntpq suite then get the output from ntpq -pcrv and it will provide deeper details.

Upvotes: 0

Related Questions