Re: ntpd time slewing
David Cureton wrote:
Tom,
I had exactly the same situation. I pulled my hair out trying to find why one
machine was operating fine whilst another was dropping time at 4 seconds an
hour. I recall that the ntpd on the failing machine was always droping out of
sync when the error became to great.
I went through the same process as you have almost carbon copy.
Someone suggested that the scsi-ide modules may be a cause. Which I thought
was entirely possible as one of my machines had a CD -burner thus has
scsi-ide loaded. I was never able to prove this - removing the module didn't
seem to have great effect.
I did find in the end that biggest impact was which servers I synced to. I
removed the list of servers from the ntp.conf file and narrowed it down to a
couple that seemed not to cause this hugh error from accumulating on the
flaky machine.
This was background work so my debugging process was probably not very
'scientific'
Finally I had to configure a Solaris fileserver with xntpd to act as the local
network ntp server. The flaky debian box seemed to work ok syncing to the
Solaris box - so I left it at that.
The server list in the ntp.conf file on my behaving box is:
server ntp.cs.mu.oz.au
server ntp.adelaide.edu.au
server time.esec.com.au
server tictoc1.tip.CSIRO.AU
Although this is probably half way around the world at least they are a known
good set.
Thanks for the response.
I was able to get things working.
I was running into a problem where I set up adjtimex 3 years ago.
As the computer aged, the values for adjtimex were no longer valid and ntp
was fighting to keep things in synchronization. Eventually it was no longer
able to keep up.
I purged adjtimex and ntp and it still didn't work.
Until I rebooted the PC (this cleared out the kernel drift values)
and now I'm running very well.
--
Somewhere, something incredible is waiting to be known.
-- Carl Sagan
Reply to: