[ntp:questions] NTP, GPSD & PPS

David Lord snews at lordynet.org
Tue Dec 9 19:23:40 UTC 2014


Sander Smeenk wrote:
> Hi,
> 
> I run a stratum 1 server which has a Garmin LVC 18x connected to its ttyS0.
> The GPS provides a PPS signal via serial and i use gpsd to provide the
> NMEA sentences and pulse data in shared memory to NTP.
> 
> This partly works. NTP syncs against the PPS signal but the NMEA signal
> is always marked as falseticker even though i managed to bring down the
> offset to -1.5ųsec average by fudging the time a bit. The NMEA signal
> offset fluctuates a lot. From ~ -65ųsec to ~ +75ųsec.
> 
> The GPS provides 9600bps serial comms. Would it help to speed this up to
> 19200bps? I've already disabled all NMEA sentence output for sentences that
> "aren't useful for timekeeping" but at this moment i have to use external
> clocks to sync against.
> 
> Few questions:
> 
> 1) Can i get a 'true PPS sync' with this setup?
> Eliminating gpsd so 'ntpq -p' shows 'oSHM(1)' instead of '*SHM(1)' ?

Hi

Jun 21, 2009: My Garmin 18x LVC gave just acceptable
performance with the NMEA driver due to having to tune the
fudge offset at almost the limit that avoided the wrong
second. For PPS I used the ATOM driver and was getting an
offset of < 6us.

Shortly afterwards Garmin released a firmware fix which
fortunately I avoided as the nmea output could over-run into
the following second.

I'd need to search my backups for the exact server and fudge
config lines.

Currently I'm running NetBSD-6/i386 and ntpd 4.2.7p476 and my
ntp.conf for a Sure GPS has:

tos minsane 3
tos orphan 10
tos mindist 0.4
server 127.127.20.2 mode 18 prefer
fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb
server 127.127.22.2 minpoll 4 maxpoll 4
fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb

plus one local peer and four local servers

NB. the mode and fudge time2 are specific for the Sure GPS.


David


> 2) What could i possibly do to get NTP to sync/accept the NMEA data,
> other than set it as a truechimer in the configuration?
> 
> 3) Why does last_event show clock_alarm for the PPS SHM signal in assoc?
> 
> 
> At this moment my 'ntpq -p' looks like:
> 
> | # ntpq -np
> |      remote           refid      st t when poll reach   delay   offset jitter
> | ==============================================================================
> |  127.127.28.0    .NMEA.           0 l   10   16  377    0.000  -52.910 12.585
> | *127.127.28.1    .PPS.            0 l    9   16  377    0.000   -0.002 0.002
> | -193.67.79.202   .PPS.            1 u   50   64  377    3.690    0.331 0.073
> | +193.79.237.14   .PPS.            1 u   48   64  377    2.753    0.128 0.725
> | +80.94.65.10     .PPS.            1 u   63   64  377    3.226    0.005 0.498
> | -130.89.0.19     103.52.146.131   2 u   30   64  377    5.417   -0.100 0.041
> 
> | # ntpq -c rv
> | associd=0 status=0415 leap_none, sync_uhf_radio, 1 event, clock_sync,
> | version="ntpd 4.2.6p5 at 1.2349-o Wed Oct  9 19:08:06 UTC 2013 (1)",
> | processor="x86_64", system="Linux/3.13.0-39-generic", leap=00, stratum=1,
> | precision=-23, rootdelay=0.000, rootdisp=0.386, refid=PPS,
> | reftime=d8318503.7827c0d3  Tue, Dec  9 2014 15:26:11.469,
> | clock=d831850e.45ff40f3  Tue, Dec  9 2014 15:26:22.273, peer=53550, tc=4,
> | mintc=3, offset=0.001, frequency=-19.125, sys_jitter=0.003,
> | clk_jitter=0.001, clk_wander=0.000
> 
> | # ntpq -c as
> | ind assid status  conf reach auth condition  last_event cnt
> | ===========================================================
> |   1 53549  9024   yes   yes  none    reject   reachable  2
> |   2 53550  964b   yes   yes  none  sys.peer clock_alarm  4
> |   3 53551  931d   yes   yes  none   outlyer              1
> |   4 53552  9424   yes   yes  none candidate   reachable  2
> |   5 53553  9424   yes   yes  none candidate   reachable  2
> |   6 53554  931d   yes   yes  none   outlyer              1
> 
> 
> Thanks for any input!
> 
> -Sander.



More information about the questions mailing list