Re: ntpd time slewing
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.
Cheers,
David
On Friday 05 September 2003 22:26, Tom Allison wrote:
> I'm having some trouble getting a server to keep proper time.
> What's got me at a loss is that this is one of two almost identical
> machines and the other one is fine, always has been. The only difference I
> can see in the configurations are the $NTPSERVERS lists. They are
> different based on their geographic proximity to different time servers.
> (these servers are not in the same city)
>
> This is what I've been doing with the "broken" time-server this morning.
>
> purged adjtimex.
> purged everything matching 'dpkg -l ntp*'
>
> 'apt-get install -t testing ntpdate ntp-simple'
> (this might have been -unstable)
> Allowed it to everwrite anything left behind (/etc/init.d/ntp-simple).
>
> added stratum 2 time servers to the ntp-servers default file:
> NTPSERVERS="clock.sjc.he.net ntp.ucsd.edu ntp1.sf-bay.org ntp2.sf-bay.org
> time.berkeley.netdot.net"
>
> set the time using 'ntpdate -b {list of time servers here}'
> a couple of times in a row. Came up with a nice 0.00xx response.
>
> I then started up ntpd and here is what I have in the logs:
> 5 Sep 04:38:55 ntpd[18631]: ntpd exiting on signal 15
> 5 Sep 04:43:24 ntpd[18928]: signal_no_reset: signal 17 had flags 4000000
> 5 Sep 04:47:42 ntpd[18927]: time set -0.052783 s
> 5 Sep 04:47:42 ntpd[18927]: synchronisation lost
> 5 Sep 05:03:54 ntpd[18927]: time reset -1.998872 s
> 5 Sep 05:03:54 ntpd[18927]: synchronisation lost
>
> Started ntpd at 04:43:24.
> 20 minutes later I'm almost 2 seconds off.
> That's almost a minute a day.
>
> I have no /etc/ntp.drift file
> I have nothing in /var/lib/ntp/
> I have not rebooted since any of this began. Don't believe it's necessary
> yet.
>
> Update:
> 5 Sep 05:18:11 ntpd[18927]: time reset -1.902610 s
> 5 Sep 05:18:11 ntpd[18927]: synchronisation lost
>
> Does this mean it's getting better?
> compared to 05:03:54 time entry above maybe, but 0.09 seconds isn't
> something to write home about...
> Or is there something else I need to do in order to fix it up?
>
> For a simple 'star' topology on private LANs, is there a better solution
> for the server than ntpd?
>
> Thanks in advance.
Reply to: