[ntp:questions] Re: Frequent time reset messages
bob.robison at swri.org
Mon Dec 5 13:13:25 UTC 2005
I appreciate all of the advice that has been offered, and I've learned
more about how to manage/monitor NTP which is definitely good. I've
also learned to watch my back a little better :-)
It turns out that we had a bad Symmetricon server, where the network
interface would totally drop out. While we were waiting for a
replacement someone decided to run a cron job on one of the other
machines in the network that would ssh to each of these diskless nodes
I've been looking at, and run rdate -s to synch to this other server.
When we installed the replacement Symmetricon, whoever put this cronjob
in forgot to disable it --- and I never knew about it. So, while I've
been trying to figure out why ntp was having jumps in the calculated
offset, the problem was due to someone else mucking with the clock!
Anyway, all seems well now. Thanks again, everyone.
On Mon, 05 Dec 2005 03:53:30 -0800
ega <egauselmann at beit.de> wrote:
> Bob Robison schrieb:
> > I've tried setting the Hz down to 100, but it didn't help -- and
> > seems to have caused other timing problems, but I may revisit that
> > at some point. I do believe the problem is lost interrupts, but I
> > don't know how to be sure without hacking the firewire driver and
> > trying to determine how long it is in there. And if I found out,
> > I'm not sure what I could do.
> > At the moment I'm trying to get it to simply step/adjust more often.
> > I've adjusted minpoll/maxpoll to 4 (to get 16 secs) and I understand
> > that the default step threshold is 128ms. However I still see
> > offsets that are larger than that, and the 'steps' only occur every
> > 20 or 30 minutes. How can I have it happen more often?
> If the problem is not due to lost interrupts you might want to try
> this: stick the ntpd process with a specific CPU. Execute
> taskset -p 1 `pidof /usr/sbin/ntpd`
> The program 'taskset' is out of 'schedutils' from here:
> The package might already come with your distro. If this settles
> down the offset watch out for a recent kernel with the SMP+TSC
> problem solved.
> questions mailing list
> questions at lists.ntp.isc.org
More information about the questions