On 04/25/2013 10:46 AM, Tanstaafl wrote: > On 2013-04-25 10:40 AM, Michael Mol <mike...@gmail.com> wrote: >> For contrast, having all nodes sync to pool.ntp.org results in time >> variance of up to 2-3 minutes across a dozen or so machines. > > That makes no sense... > > Not calling you a liar or anything, but it just doesn't make sense. > > I can see that it might take each system different times to get fully > sync'd, but for them to consistently vary by this amount? No, something > else is wrong. > > Are these virtualized servers?
Some are virtualized, some are hosts, some are standalone. When all machines were configured to speak to pool.ntp.org, the variance was high. Obviously more so any time a guest was using its host's clock, and both guest and host were trying to adjust. There was still significant difference even between standalone systems. pool.ntp.org pulls from a huge pool of timeservers, and there is visible variance between more than a few of them. It's a volunteer effort. *shrug* Unfortunately, I don't have the exact variances in my notes. When I used a single standalone to connect to pool.ntp.org, and had all other systems (standalone, virtualized and guest) connect to that standalone system, virtually all variance went away. The stability of having a single local time source for all but one local machine to sync against overcame the instability caused by having host and guest ntp clients stacked. Of course, ideally, you want VM guests to rely on the VM host for their clock, and have the VM host configured with a good time source. And you would want all bare iron configured to talk to a small pool of tightly synchronized time servers. And if you can trust your layer 2 (or secure your layer 3 with, e.g. ipsec), you may further benefit from setting up a multicast time source. Further, ideally, you want a stratum 1 time server locally.
signature.asc
Description: OpenPGP digital signature
