NTP PPS False Ticker?

stephenw10

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

AWBbox

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.

stephenw10

Ah, that's interesting. I might have done exactly that same thing. Let me dig out that rig....

stephenw10

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

AWBbox

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.

stephenw10

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

AWBbox

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.

kiokoman

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

stephenw10

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.

kiokoman

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

stephenw10

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>

kiokoman

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

stephenw10

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

kiokoman

yeah, have fun with that when you have the time

stephenw10

Those micro-seconds all add up.