| Re: [chrony-users] Best way to synchronize dispersed VM’s |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On 05/07/2018 08:58 AM, Bill Unruh wrote:
On Mon, 7 May 2018, Nicolas Embriz wrote:
I have some legacy VM’s/ instances dispersed around the world
currently using npt and pool.ntp.org.
Note tha VMs are pretty horrible timekeepers at the best of times. The best
thing is to run ntp on the real hardware-- the host for the VMs, and
have the VMs get their time from
that .
"The right tool for the right job" -- Scotty, _Star Trek_
I've worked with a number of VM objects for the past few years, and have
tried to use the "trick" of running NTP in the host and having the
virtual objects sync to them. Still have time differences.
The problem isn't the NTP daemon running on the host; it's the
slipperiness of clock accuracy in the virtual objects. NTP (and CHRONY)
make the assumption that the clock in the "computer" is driven by a
crystal oscillator or AC power-line frequency.
Crystal oscillators in modern computing devices have a tracking accuracy
of under 1 ppm, closer to 0.010 ppm. Very few modern devices track
power-line frequency anymore.
Virtual clocks have considerably worse tracking accuracy, so the clock
in a VM object can't be regulated nearly as well as one in bare iron.
Short story: I had an automation server running on bare iron for years.
Time tracking was excellent, even without NTP running. When $DAYJOB
moved that server to a virtual environment, the clock started running
slow at times. At one point, the clock was running four hours behind
wall time, which pissed the customers off no end. The "fix" was to run
NTPdate every hour against an external time standard, a fix that
continues to this day. No more unpredictable clock drift.
At satchell.net, I've added an GPS-based NTP appliance. One server
slaves to that (and other Stratum 1 servers). Everything else slaves to
that. Last time I checked time accuracy against WWV, all the computers
were well within one second of the radio clock time.
From some things you said, you don't own the VM hosts. That can be
a...problem.
Also, latency is not as important as jitter. If you have a constant
latency, the chronyd algorithms can take that into account. Then there
is the false-ticker problem, but that's another issue.
(N.B.: if you plan to use a commercial NTP server for your reference
time base, make sure it can handle all the traffic on your network.
Embedded IP stacks tend to be fragile, particularly in consumer-grade
products. When I got my GPS-based NTP appliance, I found that I had to
use a VLAN to isolate the poor thing from the traffic on my network.
Otherwise the TCP/IP stack would choke. That's also why ONE server
synced with the appliance, and served time to the rest of my network.)
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.