[ntp:questions] NTP, GPSD & PPS

William Unruh unruh at invalid.ca
Tue Dec 9 17:46:31 UTC 2014


On 2014-12-09, Sander Smeenk <ssmeenk at freshdot.net> 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.

Who cares? If the system is locking on to the PPS that is far far
greater accuracy than you will ever get from nmea. Over 10000 times
better. Not sure what your preceived problem is. The nmea is only good
for getting the seconds time. Not more accurate time. You do not want it
involved in time setting if the PPS is working. 

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

I presume that the unreadable (to me) symbol was milli not micro
seconds. I do not believe that one could get the nmea down to
microseconds. As I understand it the gps device sends out the nmea when
it has time. Ie, much of the fluctuation is internal rather then
transmission, although of course transmission is variable as well
(consiidering that the length of the sentences fluctuate). 

>
> 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)' ?

What is untrue about the gpsd pps?

>
> 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?

nmea will always have very bad fluctuations. You want to use the PPS. 

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