[ntp:questions] Re: clock not synching with low stratum time server

Tom Smith smith at cag.lkg.hp.com
Tue Jun 21 13:52:52 UTC 2005


sbalaji79 at gmail.com wrote:
> Hi,
> 
> 
> Following are the information that you have requested:-
> 
> 
> 1) Hardware is alpha and Os is Tru64
> 
> 
>  XNTPDC -P output ( every 900 seconds)
>  -------------------------------------
> 
> 
> 
> 
> remote           local      st poll reach  delay   offset(secs)
> disp^M
> =======================================================================
> =LOCAL(0)        127.0.0.1       12   64    3 0.00000  0.000000 3.93846
> +cla2astr        5.0.0.0         16   64    0 0.00000  0.000000 0.00000
> +cla3astr        5.0.0.0         16   64    0 0.00000  0.000000 0.00000
> =timeclripfa     131.98.196.54    2   64    3 0.00188 -0.174708 3.93811
> 
> 
> remote           local      st poll reach  delay   offset    disp
> =======================================================================
> *LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00189
> +cla2astr          10.0.0.1        14   64   17 0.00049 -0.275757
> 0.93919
> +cla3astr          10.0.0.1        16   64    0 0.00000  0.000000
> 0.00000
> =timeclripfa     131.98.196.54    2   64  377 0.00285  0.477008 0.00142
> remote           local      st poll reach  delay   offset    disp^M
> =======================================================================
> *LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00189
> +cla2astr           10.0.0.1        14   64   17 0.00049  0.191304
> 0.43945
> +cla3astr           10.0.0.1        14   64  374 0.00049  0.993265
> 0.00208
> =timeclripfa     131.98.196.54    2   64  377 0.00284  1.122346 0.00143
> 
> 
> remote           local      st poll reach  delay   offset    disp^M
> =======================================================================
> *LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00191
> +cla2astr            10.0.0.1        14   64  377 0.00049  0.462898
> 0.00200
> +cla3astr            10.0.0.1        14   64  277 0.00049 -0.428132
> 0.00192
> =timeclripfa     131.98.196.54    2   64  377 0.00188  1.834147 0.00143
> 
> 
> The offset value of server timeclripfa  increased
> 0.5-0.7s(approximately) every
> 900 seconds interval. After around three days , xntpdc -p value showed
> as following:
> remote           local      st poll reach  delay   offset    disp
> =======================================================================
> =LOCAL(0)        127.0.0.1       12   64  377 0.00000  0.000000 0.00191
> *cla2astr            10.0.0.1        13 1024  376 0.00615  0.002557
> 0.02705
> +cla3astr           10.0.0.1        14 1024  377 0.00049 -0.000086
> 0.01656
> =timeclripfa     131.98.196.54    2 1024  377 0.00383 131.74644 0.01530
> 
> 
> Drift file has got the following value : 1.470(after 3 days).
> 
> 
> I used local clock as a fall back reference just in case server
> timeclripfa
> goes down.
> 
> Other local peer servers ( cla2astr,cla3astr) also has approximately
> same kind of stats as this one(cla2astr) i.e 130s drift after three
> days.
>  
>                                                
> Thanks,
> Balaji
> 

Balaji,

Your client has 5 sources of time - the local clock, 3 peers using their
local clocks (one apparently down), and one actual server. NTP is looking
for some consensus in the time among all its servers and peers. What
I believe is happening is that all of the client systems are initially
closer to agreement with each other than with the server (they all choose
to synch with the first client), so they form that consensus among
themselves. The actual server, in the meantime, is proceeding forward at
a different frequency and diverges even further, so they all ignore it and
remain synchronized to one another instead.

You should have at least 3, preferably 4, real servers configured for
each client. If this is not possible, you will have to remove the local
clock (and probably the peers) from each client ntp.conf for at least as
long as it takes for each client to stabilize against the real server and
establish a characteristic drift rate. To re-initialize everything properly
on each client, you should stop (x)ntpd, delete ntp.drift, set the time
using ntpdate, and then start (x)ntpd with only real servers in ntp.conf.

You should verify that the server itself is a proper precision server,
configured and behaving properly, and that it does not have an absurd drift
rate. It does not appear to be unstable from the above data, but it or its
server(s) might, for example, be phony servers serving out local clocks.

-Tom



More information about the questions mailing list