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:

    pf_ntp_status.jpg
    ntpq1.jpg

    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!


  • Netgate Administrator

    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.

    pf_ntp_status2.png

    This is looking good to me but always interested to get feedback and comparisons from others with a similar setup.


  • Netgate Administrator

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


  • Netgate Administrator

    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).

    pf_ntpq_2.png

    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.


  • Netgate Administrator

    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.


  • LAYER 8

    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


  • Netgate Administrator

    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. ๐Ÿค”


  • LAYER 8

    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


  • Netgate Administrator

    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>
    

  • LAYER 8

    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


  • Netgate Administrator

    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


  • LAYER 8

    yeah, have fun with that when you have the time ๐Ÿ˜ƒ


  • Netgate Administrator

    Those micro-seconds all add up. ๐Ÿ˜


Log in to reply