[ntp:questions] "ntpd[7602]: synchronized to"

Kevin Oberman oberman at es.net
Thu May 26 17:36:20 UTC 2011


> Date: Thu, 26 May 2011 10:16:16 -0700
> From: Florin Andrei <florin at andrei.myip.org>
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> 
> On 05/26/2011 09:49 AM, Chuck Swiger wrote:
> > On May 26, 2011, at 9:28 AM, Florin Andrei wrote:
> >>
> >> So, basically you're saying the "quality" of the NTP servers fluctuates for some reason and this machine is flipping back and forth between them?
> >
> > Evidently yes for your case.  With only two servers, it may not be possible to find a best intersection via ntpd's variant of Marzullo's algorithm:
> >
> >    http://en.wikipedia.org/wiki/Marzullo%27s_algorithm
> 
> It's kind of what I intuitively expected.
> 
> I'm a tad reluctant to tell the clients to use the entire fleet of local 
> NTP servers, albeit they are of similar quality. These 3 clients are 
> members of a DB cluster and it's more important to keep them in sync 
> with each other, rather than in sync with some abstract "true time". So, 
> if some local NTP servers start wondering off and fracture the cluster 
> time-wise, that's bad. Hence the tendency to keep the config tight and 
> small.

Using more ntp servers should greatly lessen the change of time
"wandering off" by fixing the problem you are seeing.

Right now you have two servers, If one goes bad and its time is invalid,
there is no way for client to tell which is bad and different systems
may choose different servers to believe, one of which is bad. This WILL
cause your system to "start wandering off".

You really should have 4 or more servers for robustness. The normally
offered "good" numbers are 4, 6, 7, 8. If you have multiple servers,
both systems should be trusting the same set of servers and, if one does
start to drift for any reason, your systems will stop trusting it and
it will be out-voted by working systems.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



More information about the questions mailing list