4 ms·

You might be doing too much work at the wrong level of abstraction. VMs should use host clock synchronization. It requires some work and coordination, but it el

You might be doing too much work at the wrong level of abstraction. VMs should use host clock synchronization. It requires some work and coordination, but it eliminates the need for ntp in VMs entirely. Hosts should then be synced using PTP or a proper NTP local stratum (just get a proper GNSS source for each DC if you have then funds). https://tsn.readthedocs.io/timesync.html https://tsn.readthedocs.io/timesync.html Deploy chrony to bare metal servers wherever possible.

rnijveld 2y ago
Our project also includes a PTP implementation, statime (https://github.com/pendulum-project/statime/ https://github.com/pendulum-project/statime/), that includes a Linux daemon. Our implementation should work as well or even better than what linuxptp does, but it's still early days. One thing to note though is that NTP can be made to be just as precise (if not more precise), given the right access to hardware (unfortunately most hardware that does timestamping only does so for PTP packets). The reason for this precision is simple: NTP can use multiple sources of time, whereas PTP by design only uses a single source. This gives NTP more information about the current time and thus allows it to more precisely estimate what the current time is. The thing with relying purely on GNSS is that those signals can be (and are in practice) disrupted relatively easily. This is why time synchronization over the internet makes sense, even for large data centers. And doing secure time synchronization over the internet is only practically possible using NTP/NTS at this time. But there is no one size fits all solution for time synchonization in general.
xorcist 2y ago
This makes sense. The clock is just another piece of hardware to be virtualized and shared among the guests. But last time I said that with some pretense of authority, someone shoved me a whitepaper from VMware that said the opposite. Best practice was stated be to sync each guest individually with a completely virtual clock. I'm not sure I agree, but at least I try to be open to be possibility that there are situations I had not considered. If anyone else knows more about this, please share.
- yjftsjthsd-h 2y ago
  > a whitepaper from VMware that said the opposite Did it say why?
ComputerGuru 2y ago
We've had issues relying on ESXi host/guest time synchronization, depending on the guest OS, and found this to be a better solution.
hcfman 2y ago
And by funds. That’s typically less than 100 euros with a Raspberry Pi

rnijveld 2y ago

Our project also includes a PTP implementation, statime (https://github.com/pendulum-project/statime/ https://github.com/pendulum-project/statime/), that includes a Linux daemon. Our implementation should work as well or even better than what linuxptp does, but it's still early days. One thing to note though is that NTP can be made to be just as precise (if not more precise), given the right access to hardware (unfortunately most hardware that does timestamping only does so for PTP packets). The reason for this precision is simple: NTP can use multiple sources of time, whereas PTP by design only uses a single source. This gives NTP more information about the current time and thus allows it to more precisely estimate what the current time is. The thing with relying purely on GNSS is that those signals can be (and are in practice) disrupted relatively easily. This is why time synchronization over the internet makes sense, even for large data centers. And doing secure time synchronization over the internet is only practically possible using NTP/NTS at this time. But there is no one size fits all solution for time synchonization in general.

xorcist 2y ago

This makes sense. The clock is just another piece of hardware to be virtualized and shared among the guests. But last time I said that with some pretense of authority, someone shoved me a whitepaper from VMware that said the opposite. Best practice was stated be to sync each guest individually with a completely virtual clock. I'm not sure I agree, but at least I try to be open to be possibility that there are situations I had not considered. If anyone else knows more about this, please share.

yjftsjthsd-h 2y ago
> a whitepaper from VMware that said the opposite Did it say why?

ComputerGuru 2y ago

We've had issues relying on ESXi host/guest time synchronization, depending on the guest OS, and found this to be a better solution.

hcfman 2y ago

And by funds. That’s typically less than 100 euros with a Raspberry Pi