NTP PPS False Ticker?
-
Ah, that's interesting. I might have done exactly that same thing. Let me dig out that rig....
-
Hmm, nope. Still doesn't choose the GPS as active peer even though it uses it for PPS. It's a mystery!
[2.5.0-DEVELOPMENT][admin@2220.stevew.lan]/root: ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 14 16 377 0.000 -0.008 0.008 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 +194.80.204.184 .GPS. 1 u 27 64 377 21.258 2.691 12.554 +85.199.214.98 .GPS. 1 u 26 64 377 12.647 2.148 18.145 +183.ip-51-89-15 85.199.214.99 2 u 26 64 357 10.943 2.774 16.112 *85.199.214.100 .GPS. 1 u 25 64 377 12.545 2.376 15.849 +195.195.221.100 .GPS. 1 u 22 64 377 20.636 2.231 23.095 +51.148.141.63 ( .GPS. 1 u 19 64 377 21.229 1.217 16.592 +slardar.parseq. 162.221.37.4 2 u 20 64 177 11.186 1.966 22.652 +ariel.rovny.net 193.79.237.14 2 u 21 64 177 11.442 2.556 8.813
Yet I have another firewall that has a USB connected GPS, and hence crap jitter, that does:
remote refid st t when poll reach delay offset jitter ============================================================================== *GPS_NMEA(0) .GPS. 0 l 5 16 377 0.000 2.983 1.989 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.001 +ntp1.wirehive.n 92.21.53.217 2 u 36 64 377 12.244 6.073 17.692 +162.159.200.1 10.21.8.251 3 u 57 64 177 10.526 6.739 7.564 -87.242.168.84 ( .UPPS. 1 u 5 64 377 19.702 6.624 14.986 -mail.redwebonli 194.80.204.184 2 u 1 64 367 25.840 6.792 15.137 +185.83.169.27 .GPS. 1 u 55 64 373 18.209 7.150 18.224 -electra.pinklem 140.203.204.77 2 u 24 64 277 10.901 9.144 8.956 +85.199.214.100 .GPS. 1 u 23 64 377 12.245 6.794 8.107 -ntp.uk.eria.one 85.199.214.102 2 u 32 64 277 11.116 -7.516 10.876
-
Sorry, I should have included the output I get from ntpq as well, "o" means that the peer is the active one in the same way that "*" does except the former is derived from a PPS signal (Documentation here).
I'm not sure how the first host from your previous screenshots could have two peers active at the same time? I did configure Serial GPS to be the preferred clock on mine but I've never seen more than one active peer before.
-
Mmm, tweaking the fudge times seems to have got me there though with a 3ms offset....
[2.5.0-DEVELOPMENT][admin@2220.stevew.lan]/root: ntpq -c pe remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 9 16 377 0.000 2.998 0.001 0.pfsense.pool. .POOL. 16 p - 64 0 0.000 0.000 0.000 -ntp3.wirehive.n 195.66.241.2 2 u 46 64 377 12.833 1.890 0.440 -ams.aput.net 131.176.107.13 2 u 43 64 177 15.963 2.575 1.267 -jdrcomputers.co 206.189.118.143 3 u 38 64 225 10.913 -1.082 0.380 +ns1.do.steersne 195.66.241.2 2 u 111 64 176 11.381 3.048 0.231 -ntp1.wirehive.n 195.66.241.10 2 u 53 64 377 11.836 2.332 0.318 +68.183.253.148 85.199.214.102 2 u 112 64 332 11.772 2.819 0.233 +85.199.214.102 .GPS. 1 u 50 64 377 12.514 2.645 0.402 -fifi.m.faelix.n 90.155.74.42 3 u 47 64 373 18.100 1.513 0.176
Hmm
-
That's looking better, did you have to do anything to get just one active peer? I ended up leaving the server alone for a couple of days at a time to 'settle' in between trying different things so maybe worth leaving yours a while and seeing how it fares.
-
afaik in the first screenshot of steve only the pps is taken from the GPS_NMEA, and the reference clock is taken from 85.199.214.100
false ticket maybe?
you restarted ntpd 2 hours ago but check now if you are still on one active peer or is back to the same situation
with if you can ntpq -crv -pn -
Yes I had assumed it was using the GPS only for PPS. I was never sure why though since the GPS always looks like a good source.
Still looks good now though apart from the offset. Not 100% sure what is offset from what though. Or why it doesn't correct if everything is showing an offset.
-
i had that problem on my raspberry pi with the gps hat, i solved it forcing my gps to send only $GPMRC and set the driver with server 127.127.20.0 mode 17 where 16 is for 9600bps and +1 for process $GPMRC only plus fudge 127.127.20.0 flag1 1 for the pps
-
Mmm, I'm using only GPGGA:
<gps> <type>MediaTek</type> <speed>16</speed> <nmea>2</nmea> <extstatus>yes</extstatus> <autocorrect_initcmd>yes</autocorrect_initcmd> <initcmd>JFBNVEsyMjUsMCoyQg0KJFBNVEszMTQsMCwwLDAsMSwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCwwLDAsMCoyOQ0KJFBNVEszMDEsMioyRQ0KJFBNVEszMjAsMCoyRg0KJFBNVEszMzAsMCoyRQ0KJFBNVEszODYsMCoyMw0KJFBNVEszOTcsMCoyMw0KJFBNVEsyNTEsOTYwMCoxNw0K</initcmd> <nmeaset> <gpgga>1</gpgga> </nmeaset> <port>cuau2</port> <fudge2>0.51</fudge2> <flag2>yes</flag2> <flag1>yes</flag1> <flag3>yes</flag3> <gpsminpoll></gpsminpoll> <gpsmaxpoll></gpsmaxpoll> <fudge1>0.003</fudge1> </gps>
-
yes but your gps is sending out all the sentences, maybe?
i have this on my /etc/rc.local/bin/echo -e '$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r\n' > /dev/ttyAMA0 #diable all except GPMRC
but this is specific for my gps chip
so the output from my gps is like this
pi@raspberrypi:~ $ cat /dev/gps0 $GPRMC,204531.000,A,4520.6621,N,01147.2135,E,0.10,327.93,171219,,,A*69 $GPRMC,204532.000,A,4520.6622,N,01147.2135,E,0.18,330.45,171219,,,A*6C $GPRMC,204533.000,A,4520.6622,N,01147.2135,E,0.30,335.70,171219,,,A*64 $GPRMC,204534.000,A,4520.6623,N,01147.2134,E,0.26,347.73,171219,,,A*62
there are probably other way to solve the problem, i think it's only a question of adjusting the timing between the pps and when your $GPGGA is "printed" on the serial port
with fudge 127.127.20.0 flag1 1 time1 -0.00300644 time2 0.470 refid GPS
i don't remember right now but i think that
tos mindist 0.100
helped also
-
Mmm, nope it really is just sending GPGGA. That did help as otherwise it varies what is output making it impossible to tune pretty much. Also the location data is disturbingly accurate.
Have to play with this more when I have time.Steve
-
yeah, have fun with that when you have the time
-
Those micro-seconds all add up.