[ntp:questions] running NTP as server only
cswiger at mac.com
Wed Aug 18 21:08:08 UTC 2010
On Aug 18, 2010, at 2:01 PM, folkert wrote:
>> Virtual machines make terrible timesources-- 10's to 100's of
>> milliseconds of jitter are not unusual.
> I don't think that is in all situations the case. Depends on the
> scheduling by the hypervisor.
It depends on the hypervisor, the hardware, the workload, etc.
> iirc ibm pseries lpars don't have this
> problem. That is why they have (x)ntp running in each of them normally.
The type of latency you might see from a lightly loaded box might well be a lot better than what you see from a virtual webhosting company which jams as many VMs as it possibly can before the clients yell about slow web performance...
>> If you need to run ntpd on that specific hardware, run it in the
>> "host ESX" or Xen's Dom0 instead, and not in one of the hosted
>> virtual machines.
> Yes, that is what I propose:
> - let the hypervisor sync to a reliable accure timesource
> - sync the vms to the hypervisor with some mechanism. e.g. on vmware you
> have the vmware tooling which runs in the vm and syncs time to the
> hypervisor (and also things like memory ballooning etc)
> - let the vm then distribute the notion of time it got from the
> hypervisor to clients
I agree up to the last part. The quality of time you get from querying ntpd running in the hypervisor should be noticably / obviously better than what you would get from ntpd running in a VM. Set up both and compare the jitter your clients see for yourself.
> Somewhere this week I'll test how this works: I put together what I was
> asking, a program which picks the time from the local clock and then
> "sends" this via ntp. Then I'll have two systems (which run directly on
> hardware, not a vm) that will have a couple of low-stratum servers to
> sync against as well as my vm. If they then declare my solution as a
> falseticker and/or with a high jitter, I then know it won't works.
Yes, testing is a fine idea.
More information about the questions