Hi, many thanks for the answers, Regarding how low I want to go, currently I am only testing and understanding more about this, I don’t really know the real limits but if I could get at a nanosecond-level would make me happy.
My plan is to start collecting metrics (collectd + influxdb + grafana) and try to measure the offset across all the instances, and over the time see how I could gradually start improving the offset, I would like to give a try building a GPS/PPS (raspberry pi + FreeBSD) and see how far I could get. Any ideas, suggestions more than welcome. regards. On Mon, May 7, 2018 at 6:51 PM, Stephen Satchell <[email protected]> wrote: > 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 [email protected] with > "unsubscribe" in the subject. > For help email [email protected] with "help" in > the subject. > Trouble? Email [email protected]. > >
