[ntp:questions] Observed local difference between public NTP servers and GPS

Russell King rmk at armlinux.org.uk
Sun May 31 17:25:39 UTC 2020


Hi,

I've tried searching with google to try and find an answer to my
question, but have failed, so I thought I would try asking here.

I've been running ntp for a long time under Linux, relying on ntpd
getting time over my DSL connection, and it has done pretty well.
The DSL is rather symmetric - currently around 13Mbps down with
interleaving and 500kbps up without interleaving, so I suspect the
delays on the link are asymetrical (which probably answers my
question.)

I've had a Mikroe GPS module kicking around doing nothing useful,
so today I decided to get it working with ntpd as packaged in
Debian Stable (4.2.8p12+dfsg-4).  This module contains a ublox
LEA6S, and provides both a NMEA output at 9600 baud and a PPS
signal.

I have configured the LEA6S module to disable all messages except
RMC, disabled SBAS (as recommended in the LEA6 documentation) and
configured the PPS output to use UTC.  All other parameters are
as per default (which means an antenna delay of 50ns.)

I've built the kernel to use periodic ticks, and included PPS GPIO
support.

What I've found is that my machine's current idea of time is about
7ms out compared to the GPS - and, as a result, ntpd decides that
my new GPS based server is an outlier.

sw-dsl:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_NMEA(0)     .GPS.            0 l   27   64  377    0.000   -0.125   0.004
*mcbin.armlinux. 85.199.214.99    2 s   58   64  377    0.286   -6.771   0.011
+pandora.armlinu 85.199.214.99    2 s    5   64  377    0.944   -6.888   0.036

(The GPS offset is slowly decreasing as I write this email as this
machine syncs to its new GPS.)

pandora:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-ns3.turbodns.co 85.199.214.99    2 u    8 1024  377   31.513    0.264   2.001
+gw01-dd.uitserv 10.30.0.29       2 u   51 1024  377   39.257    0.573   0.965
+time.netweaver. 85.199.214.98    2 u   52 1024  377   27.537    0.756   0.633
-flint.armlinux. 248.33.116.139   3 u  141 2048  275    1.450    0.552   0.395
-mcbin.armlinux. 85.199.214.99    2 u 1931 2048  256    1.312    0.125   0.201
*server1.quickdr .GPS.            1 u  129   64  256   29.437    0.851   6.358
+168-84.static.s .UPPS.           1 u 1047 2048  377   37.321    1.156   0.541
+ntp2.bucks.net  85.199.214.99    2 u  903 2048  377   30.933    0.796   0.797
+rt0.tfm40.portf 85.199.214.102   2 u 1043 2048  377   31.609    0.572   1.171
 ntp.mcast.net   .MCST.          16 u    -   64    0    0.000    0.000   0.031
-sw-dsl.armlinux .GPS.            1 u   12   64  377    0.942    6.887   0.033

So, the question is...

- should I fudge the new GPS PPS based ntpd to match what I'm getting
  from the Internet?
- should I fudge every explicit server entry that's getting its time off
  the 'net to bring that into line with my local GPS source?
- should I not care?

TBH, I don't care about absolute time, I just care about ntpd keeping
my machines visibly correct and in sync with each other.  However, it
seems a waste to try setting up a local GPS and then have everything
ignore it.

Thanks.

-- 
Russell King


More information about the questions mailing list