Zitat von Ryan Tucker <[email protected]>:
On Tue, Mar 25, 2014 at 5:36 AM, <[email protected]> wrote:
It depends if you use container or full virtual hosts. With typical VPS you
have a shared kernel and you are not allowed to set the hardware clock or
the kernel clock from inside the container. If the host you are running on
is synced with ntp this doesn't matter and ntp happily distributes the host
time. The downside is that ntpd run as root in this case because it don't
get the sys_time capability. If you use full virtualisation you are on the
trouble side because the virtual system think it is able to access the clock
alone but the hypervisor actually only create a virtual clock with ever
changing precision.
The container case was probably typical a few years ago, but the
current state-of-the-art is paravirtualized hypervisors. Each
instance has its own kernel and "sees" the hardware clocks directly.
The wall time is only fetched from the host on boot[1]. With such a
VPS, I end up with a lower error than any of my "real" hardware at
home, presumably due to higher-quality parts and better temperature
sensitivity. Throw in really good Internet connectivity and it's a
fine NTP server. -rt
[1] Indeed, if one doesn't run ntpd on such an instance, the clock
will drift.
http://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap-Virtualization-KVM_guest_timing_management.html
The problem is intrinsic. With "full" virtual systems the kernel of
the guest can never monopolize the CPU and therefore timings will skew
dependent on the particular load on the host. The hardware clock
doesn't matter to much for ntp because it is only read/set
occasionally. The problem lies in the detection of jitter/skew which
ntp tries to do which *can* fail badly inside a virtual guest. With
low loaded systems you will never see a problem.
Regards
Andreas
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
