Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Jan 2009 09:30:28 -0500
From:      Bill Moran <wmoran@potentialtech.com>
To:        scuba@centroin.com.br
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Time skew
Message-ID:  <20090114093028.9317f122.wmoran@potentialtech.com>
In-Reply-To: <alpine.BSF.2.00.0901141112490.41980@trex.centroin.com.br>
References:  <alpine.BSF.2.00.0901141112490.41980@trex.centroin.com.br>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
In response to scuba@centroin.com.br:
> 
>  	I'm facing some strange behavior with an skew in the system clock.
>  	The hardware is a Dell PowerEdge 2950III, running two instances of 
> FreeBSD 7.0-RELEASE-p5 - amd64 over an ESXi hipervisor.
>  	To both were allocated 4 processors and 4 GB of RAM, and dmesg for 
> both are identical.
>  	I'm using clockspeed to synchronize the clock, but just one of 
> them is delaying the clock a lot.

I doubt that clockspeed will ever work for you.  VMWare seems to "pause"
virtual machines when they're not doing anything in order to allocate
CPU for other running VMs.

>  	The hardware clock is ok as far as the other virtual machine.
>  	Where should I start to investigate?

For "supported" OS (i.e. Windows/Linux) VMWare provides special programs
to keep the clocks in sync.  I expect this is because VMWare knows that
they mangle the clock in such a way that typical clock management
software will never be able to keep it in sync.  One problem is that
most clock synching software assumes that drift is relatively constant
(and clockspeed seems to be the same) but clock drift in a virtual
machine is _anything_ but constant.

Unfortunately, VMWare has no love for FreeBSD.

We've been able to keep clocks in sync by adding a cronjob that runs
ntpdate every minute or so.  Seems draconian, but it gets the job done.

-- 
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20090114093028.9317f122.wmoran>