Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!pyrps5.pyramid.com!chetal From: chetal@pyrps5.pyramid.com (Pradeep Chetal) Newsgroups: comp.protocols.time.ntp Subject: Re: Lost NTP peer messages in syslog? Message-ID: <9106211908.AA09728@pyrps5.pyramid.com> Date: 21 Jun 91 19:08:40 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 48 >I'm sure I'll get corrections on this if I falter, but I'll answer anyway. > >The message just means that the skew between the clocks (the local clock >and the remote one that it's trying to synch with) is larger than some >threshhold, about 128 milliseconds. When ntpd synchs with a peer that's >more than the threshhold off from the local clock, it does it by setting >the time rather than calling adjtime(), and it clears the >peer-synchronization filter (array of saved time offsets from the remote >peer) in the process. This prints the ``Lost NTP peer...'' message. >What it really means is ``Cleared samples from NTP peer...''. > >In short, it's not a problem with the remote peer, but it may be a >subtle indication that your local clock (or the peer's clock) doesn't >keep very consistent time--that one system or the other locks out clock >updates for a while, e.g. over long interrupt-service times. Or that >some process besides ntpd is using adjtime() to dink with the local >clock. > > Craig I followed a little more on the "Lost NTP peer" problem and found that whenever it happens the "peer->estdisp" is greater than NTP_MAXWGT which is the maximum allowable dispersion and therefore it fails in the sanity_checking() procedure. This apparently has nothing to do with the 128 ms (I guess you are referring to #define CLOCK_MAX 0.128 /* maximum aperture (milliseconds) */) which anyways is .512 for me as I don't have XTAL defined. BUT then I just started playing with NTP and haven't looked at complete source. Actually the "peer->estdisp" is greater than NTP_MAXWGT alot of times BUT then sys.peer (in select_clock routine) is NULL most of the time and we don't see the message. Only sometimes is sys.peer non-null and I see this message. So I am NOT sure if the skew clock problem between local & remote peer is the reason. Meanwhile I am also trying to get xntp to work on our systems. Rest everything out here is NTP. I thought I will be able to use "xntp" with peer's & server's defined as "version 1" in the /etc/ntp.conf file w/o any other changes. "xntpd" starts up fine BUT I don't think it is talking to other "ntpd" peers & servers. Do I have to do anything other than this (version) so that xntpd can talk to other peer & server "ntpd" daemons. Thanks, /Pradeep