[ntp:questions] NTP Sync Issues - Solved
a.johnson at wintoncapital.com
Thu Jun 12 15:45:23 UTC 2008
We have figured out what the issue was. It turns out that it was because
of an Altiris deployment server that for some reason was conflicting
with NTP and adjusting the time on the servers. Thanks to all that
responded to my question.
From: questions-bounces+a.johnson=wintoncapital.com at lists.ntp.org
[mailto:questions-bounces+a.johnson=wintoncapital.com at lists.ntp.org] On
Behalf Of David Woolley
Sent: 10 June 2008 07:48
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] NTP Sync Issues
Adam Johnson wrote:
> Yes you are right we are running RHEL5. The strange thing is that when
> we try to sync the servers from a location that syncs correctly
> to the location with the issues then we get the same issues as the
I didn't understand that.
> servers are experiencing. You say that it could be conflicting time
> synchronisation mechanisms, do you mean that the 2 upstream servers
> conflicting or that something other than NTP is causing this? Thank
> for your help!
I was actually referring to something other than NTP, although that is
not generally an issue on Red Hat. Two conflicting servers only happens
if the server configuration is broken, although, given the number of
people who use the local clock without understanding the risks, that's
possibly not that unlikely.
In a correctly operating NTP system, you can rely on all servers and the
client being within 1 second of some concept of true time. For public
servers, and ones based on radio reference clocks, that time is UTC.
The fix for this is to choose servers which are traceable to the same
time source and to have enough independent ones that any rogue one is
outvoted by the good ones.
However, the result of having two servers on different times is either
that both get ignored, or that times hop backwards and forwards. As
your time was always hopping backwards, the indications are for
something other than ntpd forcibly changing the clock. This will give
steps at roughly equal intervals.
More likely on Red Hat, given that your steps are always positive, is
lost timer interrupts. Lost interrupts tend to be activity related, so
the interval between steps and size of steps will be more variable. To
fix that, make sure that IDE drivers use DMA and, if possible, rebuild
the kernel with HZ set to 100.
questions mailing list
questions at lists.ntp.org
More information about the questions