Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 May 2008 12:12:37 -0400
From:      Jeff Dickens <jeff@m2.seamanpaper.com>
Cc:        FreeBSD-Questions@FreeBSD.org
Subject:   Re: time drift
Message-ID:  <483C32F5.9010903@m2.seamanpaper.com>
In-Reply-To: <20080515153843.L77471@border.lukas.is-a-geek.org>
References:  <20080515185758.GA12709@ikarus.thalreit>	<20080515210819.GA12605@Grumpy.DynDNS.org>	<20080515211620.GH18488@hal.rescomp.berkeley.edu> <20080515153843.L77471@border.lukas.is-a-geek.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------060607000609090306020508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I have the opposite problem... the clocks run fast on my vmware clients.

I'm running FreeBSD 6.3 on vmware ESX server 3.0.2 on an IBM x-series 
dual Xeon.

I have this in my my loader.conf:

    kern.hz="100"
    hint.apic.0.disabled=1

The latter line made a big improvement, but it still slowly gains.  If I 
could only get linux guests to do as well.

I have ntpd running in the ESX maintenance console, and it's keeping 
good time.  I have offset less than 1 from a stratum 2 server.

I also have this in the .vmx file for the guest:

    tools.syncTime = "TRUE"


Is there anyway to "slow down" the clock just a tiny bit, so the vmware 
synctime thing can keep it correct?  The timekeeping whitepaper from 
vmware says that the synctime facility won't set the time back, which of 
course would be in general a bad idea.



Luke Dean wrote:
>
>
> On Thu, 15 May 2008, Christopher Cowart wrote:
>
>> David Kelly wrote:
>>> Its PC commodity-grade. Not all that unusual even for stuff sold
>>> claiming to be a "server". This is in no small part why ntpd exists.
>>>
>>> nptd calculates a correction coefficient and (under FreeBSD) stores it
>>> in /var/db/ntpd.drift for use on next start so as to more quickly
>>> establish a lock.
>>>
>>> So in short ntpd calibrates your clock in order to minimize the
>>> corrections required. Is The Right Thing To Do.
>>
>> We run a large number of FreeBSD servers under vmware. We've seen ntpd
>> silently die, because the drift becomes "insane." What do others do in
>> this situation? (We've resorted to croning ntpdate for VMs.)
>
> kern.hz="100"
> in /boot/loader.conf solved this problem for me.
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe@freebsd.org"

--------------060607000609090306020508--



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