[ntp:questions] Accuracy of GPS device

Miroslav Lichvar mlichvar at redhat.com
Fri Sep 2 10:33:41 UTC 2011


On Fri, Sep 02, 2011 at 09:50:05AM +0100, Miguel Gonçalves wrote:
> I found out the problem and just for the record I'll explain...
> 
> The offset is larger than the delay because NTPd is using 10.0.2.254 (more
> on this switch later) as a time source and it shouldn't because it has two
> local stratum 1 clocks that are closer (0.170 ms vs 0.583 ms) are show less
> jitter. Anyway... to prove my point I removed 10.0.2.254 (the **internal**
> switch) from the configuration and here's the result of ntpq -p as of now:

It would be interesting to see the root distances for the three
servers. I think it's reasonable to expect the weights of the stratum
1 servers to be much higher than the weight of the third server, so
the combined offset isn't affected much by the third server. But what
I think it's happening here is the high default dispersion rate (15
ppm) increases the root distance so much that the weights are not that
much different. Setting "tinker dispersion" to a more realistic value
like 1 ppm (or even to 0.1 ppm in your case, see my comment below)
should help.

You can also use "tos minclock 2" to limit the number of combined
sources. 

> $ ntpq -p 10.0.2.2
>      remote           refid      st t when poll reach   delay   offset
>  jitter
> ==============================================================================
> +10.0.2.10       .GPS.            1 u  889 1024  377    0.179   -0.066
> 0.083
> *10.0.2.9        .GPS.            1 u  391 1024  377    0.166   -0.084
> 0.051

Those are very good numbers for such high polling interval. Is the
crystal oscillator thermally stabilized? 

In any case I'd suggest to use a shorter maximum poll interval. The
default maxpoll is way too high for jitters normally seen on LANs if
you want best accuracy.

-- 
Miroslav Lichvar



More information about the questions mailing list