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" <[EMAIL PROTECTED]>
To: "Ed" <[EMAIL PROTECTED]>
Cc: <freebsd-stable@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
