[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