cpu-timer rate
Ed
ed at edslocomb.com
Wed Dec 7 15:40:26 PST 2005
With all due respect, "vmware plays fast and loose with the clocks" is not a
satisfactory technical explanation. The pdf file I linked to in my previous
post *does* offer some actual insight as to how vmware simulates i386
hardware clocks and timers. It does not, however, offer any insight as to
why it should be only a particular FreeBSD OS (specifically, FreeBSD
6.0-STABLE) which exhibits this curious behavior wherein the hosted OS has a
system clock running at precisely half the rate of that of the host OS.
I am not satisfied with "it is vmware's fault" as a technical explanation.
They might indeed have simulated the LAPIC timer or some other device
incorrectly (and subtly, such that no other OS reveals the flaw), but until
the precise nature of that error (if any) is explained, your accusation
rings hollow.
For these reasons, I believe your technically unsupported assertion that
"This is nothing to do with the core team" should be shelved, pending actual
investigation of the phenomenon.
I see a potential situation developing here in which two talented teams of
developers each regard a shared problem as an outlier, and thus blame the
other team without investigating, leaving the problem unresolved.
It is no doubt true that those of us who run FreeBSD in VMWare are a
minority of a minority, and as such should expect a bit of fiddling and
adjusting from time to time rather than continuous smooth sailing on default
configurations, but nevertheless, the problems we work around should not be
dismissed before they are understood.
--Ed
P.S.-- The current workaround for the 1/2-speed clock problem is disabling
the FreeBSD APIC device. This means FreeBSD can not be run (with a correct
system clock) in SMP mode on VMWare emulated hardware. The most recent
version of the most widely used vmware product, VMWare Workstation (5.5,
released only weeks ago), added support for dual-cpu emulation, on systems
that actually have two (or more?) processors. The workaround I found is,
I'm afraid, becoming less adequate even as we speak.
P.P.S.-- Though my aggrieved tone no doubt suggests otherwise, I would be
most happy to offer any assistance I can in getting to the bottom of this.
I've looked a bit at the ACPI (not APIC) code to try to figure out why the
kernel chooses ACPI-safe rather than ACPI-fast for the kernel timer when
APIC is disabled, but I saw no reference to the APIC device in the
clock-choosing stuff. The role of the APIC device in the kernel
clocks/timers remains opaque to me; all I know is that the release notes for
6.0 clearly state that it is now used in single-processor systems, and that
this is a change from 5.x.
----- Original Message -----
From: "Peter Jeremy" <PeterJeremy at optushome.com.au>
To: "Ed" <ed at edslocomb.com>
Cc: <freebsd-stable at freebsd.org>
Sent: Wednesday, December 07, 2005 10:22 AM
Subject: Re: cpu-timer rate
> On Wed, 2005-Dec-07 03:51:47 -0800, Ed wrote:
>>I certainly do not have a full understanding of the interactions between
>>the various FreeBSD software timers and i386 hardware clocks, but I do
>>know
>>this is not the first time we've seen a problem with the APIC/ACPI
>>timers/clocks.
>
> You have a totally different problem. In your case the system is not
> keeping correct time - this is because VMware does not provide stable
> clock interrupts - probably due to interactions between VMware and the
> host OS. In kama's case, the interrupt rate reported by vmstat -i
> does not match the numbers reported by kern.clockrate. There is no
> indication that the system is not keeping correct time.
>
>>Again, I'm no expert, but clock problems do keep cropping up here on
>>the -STABLE list, and the explanations for them to date have not been
>>consistent.
>
> AFAIR, all the problems reported here have been related to VMware
> clients. And as someone stated "VMware plays fast and loose with
> clocks".
>
>>I'm sure I'm not the only end-user who would appreciate it if the core
>>team
>
> This is nothing to do with the core team.
>
> --
> Peter Jeremy
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
>
More information about the freebsd-stable
mailing list