Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Jun 2012 21:46:37 +0300
From:      Martin Dimitrov <martin.dimitrov@mafiainc.org>
To:        Michael Sierchio <kudzu@tenebras.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Clock lagging behind on FreeBSD 9.0-RELEASE under KVM
Message-ID:  <4FCE540D.8060807@mafiainc.org>
In-Reply-To: <CAHu1Y72b-77zU0JbncCsY_H2RFP4JQuz2FYPPNcsa459ezt4Dw@mail.gmail.com>
References:  <4FCE20E7.2000202@mafiainc.org> <CAHu1Y72b-77zU0JbncCsY_H2RFP4JQuz2FYPPNcsa459ezt4Dw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Thanks, but it's not working:

# sysctl machdep.independent_wallclock=1
sysctl: unknown oid 'machdep.independent_wallclock'

I grep under /usr/src/sys for independent_wallclock and it appeared only
in ./i386/xen/clock.c, my architecture is amd64 if it matters.

On 06/05/2012 07:59 PM, Michael Sierchio wrote:
> Try
>
> machdep.independent_wallclock=1
>
> On Tue, Jun 5, 2012 at 8:08 AM, Martin Dimitrov
> <martin.dimitrov@mafiainc.org> wrote:
>> Hi,
>>
>> I am new to FreeBSD, decided to migrate a web server to FreeBSD. I
>> recently both a VPS that claim to use KVM as a virtualization service, I
>> don't know the details of the real hardware running behind nor what is
>> KVM running on. Anyway I have an issue with clock on my FreeBSD
>> installation that I can't live with. The clock is lagging behind, for
>> example running sleep 30 is really sleeping around 35 seconds not 30.
>> Also seems that NTP is not able to manage with this drift in time.
>> Before posting here I red about similar problems mostly related to
>> VMWare guests, but the solutions suggested are following:
>>
>> set kern.hz=100 or kern.hz=50 (doesn't work for me)
>> set hint.apic.0.disabled=1 (this makes the guest hangs while booting
>> also it discarding the SMP capabilities of the kernel which I assume is
>> not a good idea)
>> set kern.timecounter.hardware TSC (doesn't work for me)
>>
>> Is there any chance I deal with this time drifting issue somehow? If
>> somebody faced such issue and managed it I would be happy to try another
>> possible solution?
>> Alternatively I can switch the provider with other that is using Xen for
>> virtualization, I guess is better, but no guarantee that would not have
>> the same issue. :(
>>
>> Cheers,
>> Martin
>> _______________________________________________
>> 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"



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