In article <[EMAIL PROTECTED]>, Sankaran Balaji <[EMAIL PROTECTED]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
