[ntp:questions] NTP Sync Issues - Solved

Adam Johnson 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.

Thanks

Adam

-----Original Message-----
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
normally
> to the location with the issues then we get the same issues as the
local

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
are
> conflicting or that something other than NTP is causing this? Thank
you
> 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
https://lists.ntp.org/mailman/listinfo/questions



More information about the questions mailing list