On 2011-03-08, Chuck Swiger <[email protected]> wrote: > On Mar 8, 2011, at 1:18 PM, Steve Kostecke wrote: > >> On 2011-03-08, Chuck Swiger <[email protected]> wrote: >> >>> Seriously, each physical machine only has one RTC and crystal >>> oscillator. It's useful to run one instance of ntpd in the Dom0 (or >>> host ESX) context where it can actually work and keep this real >>> hardware clock in sync. >> >> NTP disciplines the system (i.e. kernel) clock, not the hardware >> clock on the mother board. > > That's right, although in reasonably common for platforms to > periodically write the system clock time back to the hardware > clock-- variously called the RTC/TOD/TOY clock which is in the > BIOS/EFI/firmware and keeps time when the system is off.
The RTC is _updated_, not synced, by the kernel. > Anyway, there isn't a separate RTC *or* timer crystal driving > ACPI/HPET/etc for each VM. Plus the VMs likely don't receive consistant time-slices. >> I have a Debian 6.0 system running as a VMWare guest. ntpd on this >> system has no problem disciplining the clock. > > OK. Does it do any better than using VMWare's "tools.syncTime = true"? I don't have access to the host. > Your jitter values are well over an order of magnitude worse than that > of ntpd running on a non-virtualized machine, and your offsets are > nearly an order of magnitude worse: You're comparing apples and oranges. > For all of that, your VM is doing pretty well running ntpd compared to > others I'd seen. I'd imagine the host running the VM isn't especially > busy; if it was, I wouldn't be surprised if ntpd can't manage to > discipline the clock without "tinker panic 0". The default panic threshold is 1024 seconds. >>> You are better off running ntpdate (or sntp) periodically via cron >>> in the DomUs. >> >> Perhaps in certain cases, but not across the board. > > I'd be happy to review counterexamples to my generalization... There's my example. -- Steve Kostecke <[email protected]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
