[ntp:questions] Re: Continuing with linux 2.6 + ntpd

Terje Mathisen terje.mathisen at hda.hydro.com
Mon Jan 26 08:29:07 UTC 2004


Ruben Navarro Huedo wrote:
> WARNING: Unsanitized content follows.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Have a look at this:
> 
> linux:~# ntptrace -n
> 127.0.0.1: stratum 2, offset 0.000194, synch distance 0.72052
> 193.49.205.19: stratum 1, offset 2.304254, synch distance 0.00000, refid 'GPS'
> linux:~# ntpq -pn
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +195.220.94.163  .GPS.            1 u   48   64  177   90.941  2221.20 523.981
> +145.238.110.49  .1PPS.           1 u   46   64  177  159.515  2276.20 572.888
> +138.96.64.10    .GPS.            1 u   57   64  177  277.596  2284.27 629.969
> *193.49.205.19   .GPS.            1 u   53   64  177   96.053  2206.35 485.596
> +193.49.205.17   .GPS.            1 u   51   64  177  131.519  2191.65 473.341
> linux:~# ntpq -pn
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  195.220.94.163  .GPS.            1 u   55   64    1  137.460   37.794   0.004
>  145.238.110.49  .1PPS.           1 u   58   64    1  219.715   78.921   0.004
>  138.96.64.10    .GPS.            1 u   55   64    1  135.029   33.970   0.004
>  193.49.205.19   .GPS.            1 u   58   64    1  216.734   76.427   0.004
>  193.49.205.17   .GPS.            1 u   60   64    1  239.929  120.316   0.004
> 
> 
> Between one ntpq -pn and another there is only 5 minutes.
> 
> What could be happening?

No problem at all!

The first set of measurements are taken as the system have just started 
up, gone through a few rounds (reach = 177), and just reached a stable 
state (notice the '*' before the fourth line).

At this point ntpd has determined that the clock is more than 128 ms off 
(in fact, it is about 2.2 seconds wrong, so it will then STEP the clock 
by those 2.2 seconds, reset all parameters, and restart the calculations.

When you do the second ntpd -pn you're seeing the result of this, with 
the clock brougt within about 30-80 ms of the correct time, but you're 
probably still running with a very bad estimate of the local drift value.

What does it look like 24 hours later?

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list