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@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions

Reply via email to