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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090114093028.9317f122.wmoran>