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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
