[ntp:questions] Re: xntpd keeps increasing its offset w.r.t preferred stratum 1 server

Yatin Shelke yatinruchi at sympatico.ca
Tue Nov 9 21:40:35 UTC 2004


Thanks David.

I did observe that it was not the CPU clock drifting by itself, but xntpd
itself calling ntp_adjtime() (this must be a solaris 9 system call). I ran a
while loop to see the output of ntpq -c peers, and in another window, i ran
"truss -p <xntpd pid> 2>&1 |grep adjtime", and i could see a call to
ntp_adjtime() return success, everytime i saw the offset change in the ntpq
output..
Any insight on the above observation? Also, when i stop xntpd, the clock
does not drift away.

If i want to serve time from this server to downstream machines, how helpful
is the declaration for 127.127.1.0 (server and fudge statements) in this
server? Is it needed at all? What happens if the external server goes down?
Thanks!
Yatin

"David Woolley" <david at djwhome.demon.co.uk> wrote in message
news:T1100034014 at djwhome.demon.co.uk...
> In article <m67kd.15694$Z7.528856 at news20.bellglobal.com>,
> Yatin Shelke <yatinruchi at sympatico.ca> wrote:
>
> > What I find is that on starting xntpd, my offset gradually increases
from 0
> > to somewhere between 1000 - 2000 milliseconds w.r.t the preferred
stratum 1
> > server, and then, xntpd resets itself. Any idea what is causing xntpd to
>
> It should start the reset process by the time it reaches 128ms.  If it
> has reached 1000ms in the time it takes to complete the reset sequence
> (about 20 minutes), your clock frequency is way too far outside the
> 500ppm capture range.  If the drift over this time varies by 1 second,
> the clock is unstable, so you can't even hope to do a coarse correction
> with tickadj.
>
> > behave this way, especially, when the preferred server is stratum 1, and
the
> > local CPU clock 127.127.1.0 has been fudged to stratum 11?
>
> If the clock is that bad, you should not be using a stratum 1 server,
> unless you own it.  You should also not be configuring a local clock
> as no down stream machine should be relying on time from you.  (Many
> people mistakenly configure local clock drivers.)
>
> Note that ntpd can drift out of the 128ms band once or twice in startup,
> but it shouldn't be drifting fast enough to be able to reach 1 second!





More information about the questions mailing list