Date: Thu, 17 Dec 2009 13:23:41 -0800 From: Chuck Swiger <cswiger@mac.com> To: Steve Polyack <korvus@comcast.net> Cc: Robert Fitzpatrick <robert@webtent.com>, FreeBSD <freebsd-questions@freebsd.org> Subject: Re: slow clock on FreeBSD 7.2 on vmware Message-ID: <3D62B3FC-1385-47C2-A9F3-F81D1597D9A6@mac.com> In-Reply-To: <4B2A9C1E.2010509@comcast.net> References: <4B23CD8A.50203@webtent.com> <op.u4zhl8bq5wvplz@jam-laptop> <4B291EB5.5040605@webtent.com> <4B2A9C1E.2010509@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi--
On Dec 17, 2009, at 1:01 PM, Steve Polyack wrote:
> I would really recommend switching to VMware ESXi if at all possible. I have a lot of FreeBSD VMs running under ESXi 3.5 and 4.0 that work just great with kern.hz=100 and openntpd.
The "kern.hz=100" recommendation I can certainly agree with, but there is mostly no point in running ntpd or variants anywhere except on the host machine ("host ESX" for VMware, or Dom0 for Xen). For VMware, the vmtools stuff should provide a mechanism to sync time in VMs to the host clock.
Regards,
--
-Chuck
PS: Same thing for Xen, recently discussed on the NTP pool timekeepers list:
Begin forwarded message:
> From: Chuck Swiger <cswiger@mac.com>
> Date: October 14, 2009 2:43:08 PM PDT
> To: PGNet Dev <pgnet.dev+ntp@gmail.com>
> Cc: timekeepers@fortytwo.ch
> Subject: Re: [time] what significance does the number "3.906" have in ntp?
>
> On Oct 14, 2009, at 2:10 PM, PGNet Dev wrote:
>>> Right, OK-- from your earlier mail, you mentioned something about running
>>> with Xen Dom0/DomU. There is absolutely no point to running ntpd in a guest
>>> domain-- you should only try to run ntpd in a normal OS, or, as a last
>>> resort, in the Dom0 domain.
>>
>> actually, that's not at all the recommendation I've repeatedly been
>> getting from numerous sources.
>
> Which are?
>
> A google of "ntpd DomU" returns numerous reports of problems with this, and the strong recommendation is to only run ntpd in Dom0 using independent_wallclock set to 0, *unless* your DomU's then fail to keep sane time. For example:
>
> http://www.nabble.com/Unable-to-set-system-clock-on-domU-td22042252.html
>
>>> The other domains can and should simply use the
>>> HW clock, because latencies and such for the guest domains are highly
>>> unpredictable.
>>
>> which is why the recommendation is to sync EVERY Dom0/DomU against an
>> accurate clock via ntpd ...
>
> Why, when ntpd in a DomU *can't* actually change the HW clock? See: http://xen.epiuse.com/xen-faq.txt
>
> Q: Where does a domain get its time from?
>
> A: Briefly, Xen reads the RTC at start of day and by default will track that with the precision of the periodic timer crystal. Xen's estimate of the wall-clock time can only be updated by domain 0. If domain 0 runs ntpdate, ntpd, etc. then the synchronised time will automatically be pushed down to Xen every minute (and written to the RTC every 11 minutes, just as normal x86 Linux does). All other domains always track Xen's wall-clock time: setting the date, or running ntpd, on these domains will not affect their wall-clock time. Note that the wall-clock time exported by Xen is UTC --- all domains must have appropriate timezone handling (i.e. a correct /etc/localtime file).
>
> Seriously, each physical machine only has one RTC and crystal oscillator. It's useful to run one instance of ntpd in the Dom0 context where it can actually work and keep this real hardware clock in sync. Running ntpd's in the other DomUs is almost entirely pointless; it might be useful only if Dom0->DomU time is busted, and even in that case, ntpd is unlikely to ever obtain good time synchronization running in a DomU. You are better off running ntpdate (or sntp) periodically via cron in the DomUs.
>
> Regards,
> --
> -Chuck
>
> _______________________________________________
> timekeepers mailing list
> timekeepers@fortytwo.ch
> https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D62B3FC-1385-47C2-A9F3-F81D1597D9A6>