Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not sure if ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, compiled NTP to include kernel PPS support.
GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack.
So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS.
Cgps -s and gpsmon, reports all is well, pps registers correctly...
But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS
remote refid st t when poll reach delay offset jitter
---============
*127.127.28.0 .GPSD. 1 l 21 32 37 0.000 98.447 89.508
o127.127.22.0 .PPS. 0 l 20 32 17 0.000 -63.468 27.800
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000 0.004
+212.23.8.6 195.66.241.2 2 u 129 1024 1 13.266 198.007 3.273
+212.23.10.129 85.199.214.99 2 u 134 1024 1 19.693 195.605 3.282
+178.62.18.76 85.199.214.100 2 u 135 1024 1 13.804 195.465 3.299
+185.120.34.123 85.199.214.98 2 u 130 1024 1 12.808 197.879 3.304
+51.68.198.213 85.199.214.102 2 u 132 1024 1 13.534 197.377 3.402
+95.215.175.2 178.79.160.57 3 u 131 1024 1 19.722 198.984 3.244
And then later.
remote refid st t when poll reach delay offset jitter
---============
*127.127.28.0 .GPSD. 1 l 20 32 377 0.000 -38.512 43.162
x127.127.22.0 .PPS. 0 l 19 32 377 0.000 -159.01 0.949
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000 0.004
+212.23.8.6 195.66.241.2 2 u 255 1024 1 13.615 142.618 1.953
+212.23.10.129 85.199.214.99 2 u 261 1024 1 19.799 144.028 3.384
+162.159.200.123 10.63.8.8 3 u 258 1024 1 18.501 141.995 3.016
+185.53.93.157 81.187.26.174 2 u 258 1024 1 15.385 143.600 3.045
-217.114.59.3 33.117.170.50 2 u 259 1024 1 19.927 143.014 3.364
+109.74.192.97 85.199.214.99 2 u 255 1024 1 13.578 142.723 1.864
Which does not look good, notice the x in front of PPS...
And then sometimes.... It borks.. and drops out completely and * and x disappear, and all the +.
Then go back to
remote refid st t when poll reach delay offset jitter
---============
*127.127.28.0 .GPSD. 1 l 27 64 3 0.000 34.096 1.954
o127.127.22.0 .PPS. 0 l 26 32 3 0.000 -69.865 14.194
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000 0.002
212.23.8.6 195.66.241.2 2 u 121 1024 1 13.316 200.644 0.002
212.23.10.129 85.199.214.99 2 u 118 1024 1 19.929 202.213 0.002
178.79.155.116 85.199.214.99 2 u 120 1024 1 13.391 201.057 0.002
185.121.25.242 85.199.214.99 2 u 121 1024 1 14.084 200.964 0.002
81.21.65.169 195.195.221.100 2 u 122 1024 1 17.587 200.121 0.002
178.62.6.8 68.166.61.255 2 u 122 1024 1 13.864 200.580 0.002
I'm beginning to wonder my testing using Meinberg polling every 10 seconds is causing the Pi an issue!
remote refid st t when poll reach delay offset jitter
---============
*127.127.28.0 .GPSD. 1 l 13 64 377 0.000 144.454 69.663
o127.127.22.0 .PPS. 0 l 12 32 377 0.000 59.311 19.278
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000 0.002
212.23.8.6 195.66.241.2 2 u 491 1024 1 13.316 200.644 0.002
212.23.10.129 85.199.214.99 2 u 489 1024 1 19.929 202.213 0.002
178.79.155.116 85.199.214.99 2 u 491 1024 1 13.391 201.057 0.002
185.121.25.242 85.199.214.99 2 u 492 1024 1 14.084 200.964 0.002
81.21.65.169 195.195.221.100 2 u 493 1024 1 17.587 200.121 0.002
178.62.6.8 68.166.61.255 2 u 493 1024 1 13.864 200.580 0.002
Stopped monitoring, see if it stops...
Thanks for your comments
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not sure
if ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO,
compiled NTP to include kernel PPS support.
GPS 3D fix is fine, using an outside aerial, there are no issues here
reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs
in a network rack.
So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
module) but using a FT232RL, and connected all the pins correctly, and DCD
so I can get PPS.
Cgps -s and gpsmon, reports all is well, pps registers correctly...
But here's the weird thing, it starts out okay, from what I can tell, and I
get 377 for both GPSD and PPS
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 21 32 37 0.000 98.447
89.508
o127.127.22.0 .PPS. 0 l 20 32 17 0.000 -63.468
27.800
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 129 1024 1 13.266 198.007
3.273
+212.23.10.129 85.199.214.99 2 u 134 1024 1 19.693 195.605
3.282
+178.62.18.76 85.199.214.100 2 u 135 1024 1 13.804 195.465
3.299
+185.120.34.123 85.199.214.98 2 u 130 1024 1 12.808 197.879
3.304
+51.68.198.213 85.199.214.102 2 u 132 1024 1 13.534 197.377
3.402
+95.215.175.2 178.79.160.57 3 u 131 1024 1 19.722 198.984
3.244
And then later.
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 20 32 377 0.000 -38.512
43.162
x127.127.22.0 .PPS. 0 l 19 32 377 0.000 -159.01
0.949
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 255 1024 1 13.615 142.618
1.953
+212.23.10.129 85.199.214.99 2 u 261 1024 1 19.799 144.028
3.384
+162.159.200.123 10.63.8.8 3 u 258 1024 1 18.501 141.995
3.016
+185.53.93.157 81.187.26.174 2 u 258 1024 1 15.385 143.600
3.045
-217.114.59.3 33.117.170.50 2 u 259 1024 1 19.927 143.014
3.364
+109.74.192.97 85.199.214.99 2 u 255 1024 1 13.578 142.723
1.864
Which does not look good, notice the x in front of PPS...
And then sometimes.... It borks.. and drops out completely and * and x
disappear, and all the +.
Then go back to
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 27 64 3 0.000 34.096
1.954
o127.127.22.0 .PPS. 0 l 26 32 3 0.000 -69.865
14.194
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 121 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 118 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 120 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 121 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 122 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 122 1024 1 13.864 200.580
0.002
I'm beginning to wonder my testing using Meinberg polling every 10 seconds
is causing the Pi an issue!
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 13 64 377 0.000 144.454
69.663
o127.127.22.0 .PPS. 0 l 12 32 377 0.000 59.311
19.278
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 491 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 489 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 491 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 492 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 493 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 493 1024 1 13.864 200.580
0.002
Stopped monitoring, see if it stops...
Thanks for your comments
---=============
Andrew,
Three thoughts:
-
any chance the DCD pulse is the wrong polarity? Triggering on the
trailing an not the leading edge? Might give errors typically around 100 ms
(the pulse width), but your errors seem to be more in the 250-300 ms range. -
WNRO (week number roll over) issue?
-
unless you need stand-alone operation, try commenting out the type 28
driver.
I'd suggest the NTP Questions list, but it is /very/ fussy in what e-mail
provider it accepts. Only one of my four works!
https://lists.ntp.org/listinfo/questions
Cheers,
David
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
Thanks David
I may try that list.
It is odd, it works fine, and then craps out....
And then it's happy again...
Andrew
-----Original Message-----
From: time-nuts time-nuts-bounces@lists.febo.com On Behalf Of David J Taylor via time-nuts
Sent: 03 July 2020 18:34
To: time-nuts@lists.febo.com
Cc: David J Taylor david-taylor@blueyonder.co.uk
Subject: Re: [time-nuts] Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not sure if ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO, compiled NTP to include kernel PPS support.
GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack.
So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
module) but using a FT232RL, and connected all the pins correctly, and DCD so I can get PPS.
Cgps -s and gpsmon, reports all is well, pps registers correctly...
But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 21 32 37 0.000 98.447
89.508
o127.127.22.0 .PPS. 0 l 20 32 17 0.000 -63.468
27.800
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 129 1024 1 13.266 198.007
3.273
+212.23.10.129 85.199.214.99 2 u 134 1024 1 19.693 195.605
3.282
+178.62.18.76 85.199.214.100 2 u 135 1024 1 13.804 195.465
3.299
+185.120.34.123 85.199.214.98 2 u 130 1024 1 12.808 197.879
3.304
+51.68.198.213 85.199.214.102 2 u 132 1024 1 13.534 197.377
3.402
+95.215.175.2 178.79.160.57 3 u 131 1024 1 19.722 198.984
3.244
And then later.
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 20 32 377 0.000 -38.512
43.162
x127.127.22.0 .PPS. 0 l 19 32 377 0.000 -159.01
0.949
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 255 1024 1 13.615 142.618
1.953
+212.23.10.129 85.199.214.99 2 u 261 1024 1 19.799 144.028
3.384
+162.159.200.123 10.63.8.8 3 u 258 1024 1 18.501 141.995
3.016
+185.53.93.157 81.187.26.174 2 u 258 1024 1 15.385 143.600
3.045
-217.114.59.3 33.117.170.50 2 u 259 1024 1 19.927 143.014
3.364
+109.74.192.97 85.199.214.99 2 u 255 1024 1 13.578 142.723
1.864
Which does not look good, notice the x in front of PPS...
And then sometimes.... It borks.. and drops out completely and * and x disappear, and all the +.
Then go back to
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 27 64 3 0.000 34.096
1.954
o127.127.22.0 .PPS. 0 l 26 32 3 0.000 -69.865
14.194
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 121 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 118 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 120 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 121 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 122 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 122 1024 1 13.864 200.580
0.002
I'm beginning to wonder my testing using Meinberg polling every 10 seconds is causing the Pi an issue!
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 13 64 377 0.000 144.454
69.663
o127.127.22.0 .PPS. 0 l 12 32 377 0.000 59.311
19.278
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 491 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 489 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 491 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 492 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 493 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 493 1024 1 13.864 200.580
0.002
Stopped monitoring, see if it stops...
Thanks for your comments
---=============
Andrew,
Three thoughts:
-
any chance the DCD pulse is the wrong polarity? Triggering on the trailing an not the leading edge? Might give errors typically around 100 ms (the pulse width), but your errors seem to be more in the 250-300 ms range.
-
WNRO (week number roll over) issue?
-
unless you need stand-alone operation, try commenting out the type 28 driver.
I'd suggest the NTP Questions list, but it is /very/ fussy in what e-mail provider it accepts. Only one of my four works!
https://lists.ntp.org/listinfo/questions
Cheers,
David
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On 7/3/20 8:56 AM, Andrew Hancock wrote:
GPS 3D fix is fine, using an outside aerial, there are no issues here reported with cgps -s or gpsmon, but recently I've racked mounted all my PIs in a network rack.
Have you ruled out thermal issues with the Pi being in a rack?
On 03/07/2020 13:56, Andrew Hancock wrote:
But here's the weird thing, it starts out okay, from what I can tell, and I get 377 for both GPSD and PPS
remote refid st t when poll reach delay offset jitter
---============
*127.127.28.0 .GPSD. 1 l 21 32 37 0.000 98.447 89.508
o127.127.22.0 .PPS. 0 l 20 32 17 0.000 -63.468 27.800
That's NOT ok, IMHO :-)
I think the offset and jitter for the PPS server are far too high.
Here's what my Raspberry Pi2 looks like:
$ ntpq -p
remote refid st t when poll reach delay offset
jitter
---============
*SHM(0) .SHM. 0 l 7 16 377 0.000 -90.737
65.556
oPPS(0) .PPS. 0 l 5 16 377 0.000
0.002 0.002
+ntp0... (other NTP servers omitted but 0ffset values were 1 or 2 ms)
My setup sounds like your original, with a GPS Hat and PPS on a GPIO
line. The huge difference between your remote servers and your PPS
signal suggest (as others have said) that the timing of your PPS signal
is wrong. I think that is the cause of your problems.
Steve
Andrew, outlier rejection in NTPD is not the most stable thing in the world.
You have two local refclocks that are consistently 200ms off from the "rest
of the world" and this is 10 times larger than the round trip delay to the
rest of the world.
But the local stratum 0 refclock poll interval is ten or twenty times more
frequent than the rest of the world so the local wrong clock gets to
trigger the algorithm ten times as often as the rest of the world.
The outlier rejection NTPD algorithm goes absolutely bonkers in this case.
Which is good because you see it and fix the actual problem.
Like David suggested, seeing the 200ms offset, this 200ms is a very common
default PPS pulse width so it almost certainly is triggering off the wrong
edge.
Tim N3QE
On Sun, Jul 5, 2020 at 7:50 AM Andrew Hancock <
andrew.hancock@cyrus-consultants.co.uk> wrote:
Thanks David
I may try that list.
It is odd, it works fine, and then craps out....
And then it's happy again...
Andrew
-----Original Message-----
From: time-nuts time-nuts-bounces@lists.febo.com On Behalf Of David J
Taylor via time-nuts
Sent: 03 July 2020 18:34
To: time-nuts@lists.febo.com
Cc: David J Taylor david-taylor@blueyonder.co.uk
Subject: Re: [time-nuts] Raspberry Pi NTP server
A puzzle (so I hope) I'm in the correct place.
I've built myself, many years ago an NTP server, on a RPi 1, which not
sure if ever ran properly.
It uses a u-blox6 board, connected to the Pi correctly, and PPS to GPIO,
compiled NTP to include kernel PPS support.
GPS 3D fix is fine, using an outside aerial, there are no issues here
reported with cgps -s or gpsmon, but recently I've racked mounted all my
PIs in a network rack.
So I cannot use HaTs anymore, so I cobbled together a GPS ublox6 (same
module) but using a FT232RL, and connected all the pins correctly, and DCD
so I can get PPS.
Cgps -s and gpsmon, reports all is well, pps registers correctly...
But here's the weird thing, it starts out okay, from what I can tell, and
I get 377 for both GPSD and PPS
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 21 32 37 0.000 98.447
89.508
o127.127.22.0 .PPS. 0 l 20 32 17 0.000 -63.468
27.800
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 129 1024 1 13.266 198.007
3.273
+212.23.10.129 85.199.214.99 2 u 134 1024 1 19.693 195.605
3.282
+178.62.18.76 85.199.214.100 2 u 135 1024 1 13.804 195.465
3.299
+185.120.34.123 85.199.214.98 2 u 130 1024 1 12.808 197.879
3.304
+51.68.198.213 85.199.214.102 2 u 132 1024 1 13.534 197.377
3.402
+95.215.175.2 178.79.160.57 3 u 131 1024 1 19.722 198.984
3.244
And then later.
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 20 32 377 0.000 -38.512
43.162
x127.127.22.0 .PPS. 0 l 19 32 377 0.000 -159.01
0.949
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.004
+212.23.8.6 195.66.241.2 2 u 255 1024 1 13.615 142.618
1.953
+212.23.10.129 85.199.214.99 2 u 261 1024 1 19.799 144.028
3.384
+162.159.200.123 10.63.8.8 3 u 258 1024 1 18.501 141.995
3.016
+185.53.93.157 81.187.26.174 2 u 258 1024 1 15.385 143.600
3.045
-217.114.59.3 33.117.170.50 2 u 259 1024 1 19.927 143.014
3.364
+109.74.192.97 85.199.214.99 2 u 255 1024 1 13.578 142.723
1.864
Which does not look good, notice the x in front of PPS...
And then sometimes.... It borks.. and drops out completely and * and x
disappear, and all the +.
Then go back to
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 27 64 3 0.000 34.096
1.954
o127.127.22.0 .PPS. 0 l 26 32 3 0.000 -69.865
14.194
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 121 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 118 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 120 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 121 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 122 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 122 1024 1 13.864 200.580
0.002
I'm beginning to wonder my testing using Meinberg polling every 10 seconds
is causing the Pi an issue!
remote refid st t when poll reach delay offset
jitter
---============
*127.127.28.0 .GPSD. 1 l 13 64 377 0.000 144.454
69.663
o127.127.22.0 .PPS. 0 l 12 32 377 0.000 59.311
19.278
uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000
0.002
212.23.8.6 195.66.241.2 2 u 491 1024 1 13.316 200.644
0.002
212.23.10.129 85.199.214.99 2 u 489 1024 1 19.929 202.213
0.002
178.79.155.116 85.199.214.99 2 u 491 1024 1 13.391 201.057
0.002
185.121.25.242 85.199.214.99 2 u 492 1024 1 14.084 200.964
0.002
81.21.65.169 195.195.221.100 2 u 493 1024 1 17.587 200.121
0.002
178.62.6.8 68.166.61.255 2 u 493 1024 1 13.864 200.580
0.002
Stopped monitoring, see if it stops...
Thanks for your comments
---=============
Andrew,
Three thoughts:
-
any chance the DCD pulse is the wrong polarity? Triggering on the
trailing an not the leading edge? Might give errors typically around 100
ms (the pulse width), but your errors seem to be more in the 250-300 ms
range. -
WNRO (week number roll over) issue?
-
unless you need stand-alone operation, try commenting out the type 28
driver.
I'd suggest the NTP Questions list, but it is /very/ fussy in what e-mail
provider it accepts. Only one of my four works!
https://lists.ntp.org/listinfo/questions
Cheers,
David
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.