Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jan 2009 03:01:51 +0000
From:      Adrian Wontroba <aw1@stade.co.uk>
To:        Jeffrey Williams <jeff@sailorfej.net>
Cc:        mike@jellydonut.org, dimitry@andric.com, freebsd-stable@freebsd.org, Andrew Thompson <thompsa@freebsd.org>, killing@multiplay.co.uk
Subject:   Re: FreeBSD 7, runaway clock as guest OS on Microsoft Virtual Server
Message-ID:  <20090123030151.GA51388@steerpike.hanley.stade.co.uk>
In-Reply-To: <4978C42E.5050500@sailorfej.net>
References:  <49777A7E.30904@sailorfej.net> <26ddd1750901211209k83250d7re8bb82dc2965ccd0@mail.gmail.com> <497785E2.5040007@sailorfej.net> <20090121203654.GB84399@citylink.fud.org.nz> <4977A06B.7060605@sailorfej.net> <4978C42E.5050500@sailorfej.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 22, 2009 at 11:08:30AM -0800, Jeffrey Williams wrote:

> Well this helped sort of, the clocks are running only a little fast at
> this point (roughly seven minutes gained over 12 hours), but now for
> some reason, ntpd is not resetting the clocks at all, despite multiple
> good time sources, it was working fine before the kern.hz change.  Any
> reason why that would break ntpd?

I'm afraid that most of the salient details are inaccessible at work,
but I found this necessary to get sort of acceptable[*] time keeping in
FreeBSD guests under VMware on Windows.

Run a NTP server on the host. I used the Trimble NTP implementation,
which I believe is no longer available. Disable Windows Time service.
The last thing you want is more than one time adjustment mechanism -
they fight, horribly.

Run ntpd -b every minute on the guest against the host.

Set VMware tools to not sync time.

Make several non-standard settings in the guest's .vmx configuration
file which disable time syncronisation at various points not covered by
the VMware tools setting. Information found in some VMware technical
documents. I'll dig this out tomorrow.

End result - time skips +/- a few milliseconds each minute, and takes a
while to sort itself out when the guest is suspended over a host reboot.

[*] I've a thing about time. If all you want is a clock which is no
slower than a minute out, and always goes forwards, ignore all of the
above, don't run NTP on the guest, and set VMware tools to syncronise
clocks. This is adequate for many. For my systems, I need better
time keeping to distinguish cause from effect in problems involving
interacting applications on multiple machines.

-- 
Adrian Wontroba
No matter what Cliff said, time is not the simplest thing (8-(



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090123030151.GA51388>