Hi, thanks for the prompt reply. What could be a “doable” task, could it be in the order of milliseconds?
Also what values are consider good enough as a metric to use for checking a system? regards. On Mon, May 7, 2018 at 11:00 PM, Bill Unruh <[email protected]> wrote: > > On Mon, 7 May 2018, Nicolas Embriz wrote: > > 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. >> > > You cannot unless you hook up a timing gps up to each of your computers, > replace all their crystals with muchmuch higher quality and definitely get > of > VMs. So if that is what you need, you are engaged in a hopeless task. > > >> 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. >> > > While raspberry pi's are really useful for many things, ultra high > preceision > timing is not one of them. > > > > > >> > 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]. >> >> >> >>
