[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: