NTP PPS False Ticker?
-
I've been using pfSense for a couple of weeks now and as a fairly experienced network engineer I wanted to say that I've been very impressed so far! I wanted to ask whether those more experienced with pfSense/FreeBSD than I could sanity check the current situation I have found myself in with NTP and PPS.
To give a bit of backstory, I bought a mini PC online that uses an RJ45 port for console with a standard Cisco pin-out. This means that the DCD pin is not present. To work around this I set dev.uart.0.pps_mode with a value of 1 in system tunables to capture PPS on the CTS pin instead as per the uart driver documentation. This is running with a Garmin 18x LVC and seems to be working well.
The question I have is around what I'm seeing in the NTP Status page, where the the .PPS. Ref ID is showing "False Ticker" but yet the stats from both it and .GPS. appear to be correct. I'm not seeing quite the same thing from an ntpq -p output, both screenshots are below:
A screenshot of my current NTP settings can be found here and PPS settings can be found here. If anyone could advise why I'm seeing "False Ticker" in the NTP status page I would really appreciate it.
Thanks!
-
ntpd can be a fickle beast!
When I was last doing this I found that getting the fudge times tuned was all important but you look to have <1ms there.
You can set the PPS signal to be rising or falling edge which obviously makes a pretty big difference. Have you tried that?Steve
-
Thanks Steve, it looks after all that like it was a case of RTFM on my part.
In cases where the serial GPS also provides the PPS signal, solely the "Serial GPS" settings should be configured. Only in cases where there is an additional/separate PPS source should the "PPS" settings page be touched at all.
The GPS reference now has a status of "PPS Peer" and appears to be providing both NMEA sentences and PPS as before but only using the GPS driver.
This is looking good to me but always interested to get feedback and comparisons from others with a similar setup.
-
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.813Yet 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.176Hmm
-
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 GPMRCbut 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*62there 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.100helped 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.
