[ntp:questions] Offset is always increasing

unruh unruh at invalid.ca
Thu May 23 20:36:35 UTC 2013


On 2013-05-23, Riccardo Castellani <ric.castellani at alice.it> wrote:
> You thought right, xntpd says "synchronisation lost" every 20 minutes, drift 
> file is about 855, xntpd daemon is running from about 1 year.
> In these days I 
> made several days and I restarted daemon and I waited a day to analyze offset.
>
> When I says "stable" I'm refering to value into drift file because I see always 
> the same value, that is about 855.

ntpd probably never touches it. What is the time on the file
ls -lga <driftfile>

>
> Do you suggest me to measure specific drift 
> of my hardware clock by script as documented into ntp.org, Known Hardware 
> Issues, 9.1.6 (Mac Mini and other machines having poor TICK settings) ?
> I test 
> identical server (which has same problems) I delete the drift file and I 
> restart daemon, after 2 hours :

You can tell almost nothing in 2 hrs. 
Did you see me suggesting that you plot the stuff from your log files?

Look at /var/log/ntp/loopstats and peerstats. 
from the forvmer get the drift correction. From the latter the offsets
Plot them to see what is happening. History is important, despite the
design philosophy of ntpd.


>
>
> ntpq -pn
>
>      remote           refid      st 
> t when poll reach   delay   offset    disp
>
>==============================================================================
>
> *10.2.3.5    193.204.114.233  2 u    9   64  377     0.61   -0.350    0.11
>  
> 127.127.1.1     127.127.1.1     10 l    8   64  377     0.00    0.000   10.01
>
>
> I'm worried because after many months I wouldn't like to find the same 
> behaviour.
> I have no other software to discipline time.
>
>
>
>
> Riccardo Castellani 
> wrote:
>>>>>>> I can see usually offset increases until 700 or
> 800 and it keeps
>
>>>>>>> this value,
>
>> It keeps this value means it's stable for many months, 
> it's
> doesnt change
>
>
>>>>>>> I thought you said xntpd reset it about every 20 
> minutes. How can it
>>>>>>> then have been stable for several months?
>
>>>>>>> 
> (If ntpd weren't correcting it, but only measuring it, I would suspect
>>>>>>> 
> that you had some other time discipline software that was doing a slow
>>>>>>> 
> adjustment to the clock and which thought the time was 700 to 800ms out.)



More information about the questions mailing list