[ntp:questions] Offset is always increasing

[David Lord]

Riccardo Castellani 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.
> 
> 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 :
> 
> 
> 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
> 

My guess is that your problem is because you have only two
sources, one that has offset 0 ms but stratum 10 and a second
with an offset that can increase because ntpd can't discard
the value from the local clock but will discard the stratum 1
source when its offset is large.

Are you able to use one or preferably more good time sources,
ntp, gps or radio?


David


> 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.)