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

David Woolley david at djwhome.demon.co.uk
Sat Jun 18 09:49:05 UTC 2005


In article <mailman.101.1119014403.91305.questions at lists.ntp.isc.org>,
Sankaran Balaji <balajisa at india.hp.com> wrote:

> I have a configuration which i have pasted below in ntp.conf

You have not specified anything like the minimum required information.
We need to know hardware and operating system and the output of
the ntpq peers command for each of your servers, as a minimum.

> server 127.127.1.0 version 3

Specifying version 3 on a reference clock makes no sense, but is 
probably harmless.  The first question though is why you have
the local clock configured at all; if you cannot answer that, you
should not have it.

> If i run my xntpd(4.1.1) daemon with the above configuration, i found

xntpd is version 3, so 4.1.1 cannot be xntpd!  Version 3 is obsolete.

> I ran xntpd in debug mode ( immediately after running ntpdate with
> timeclripfa.akadns.net) and found that the initial offset difference
> immediately goes up to  around 174ms.. This value keeps increasing to
> more than +100secs and my system doesnot sync at all..

If it takes less than 2.5 days to reach 100s offset, you need to fix
your clock frequency problem before you even think about running 
time discipline software.  There really isn't enough information
in your posting to speculate more, but have a look at the recent
posting about Linux and Windows lost interrupts.  (Drifting out to
100s over any period of time is a no no, but 2.5 days would mean
that you are drifting at nearly 500ppm, the maximum possible
correctable frequency error.)

> timeclripfa.akadns.net has a stratum value of 2. I believe
> that xntpd should choose a low stratum server as its time source.
> I ran ntpdate timeclripfa.akadns.net before starting xntpd.

> Is there any reason why xntpd does not choose the low startum server
> and falls back on local clock for synchronization ?

It's almost certainly being rejected as a falseticker before its
stratum can be considered.  One of the problems with local clocks
is that they give a falsely narrow error tolerance.

I think you are mis-using local clocks, and probably mis-using peering.
It is best to have at most one machine configured with the local clock as
a fallback, but if you have multiple ones, you should stagger their
stratums by at least two and should not use peer relationships, but 
establish a clear server heirarchy.

If you are going to use a local clock, you really need to have multiple
sources of true time that can outvote it.  However, most people shouldn't
have a local clock configured, and if you haven't understood why local
clocks can be undesirable, you probably shouldn't have one configured.

PS.  If at all possible, please use proper USENET software, as the 
email gateway to this newsgroup is broken.



More information about the questions mailing list