Date: Wed, 7 Dec 2005 15:39:04 -0800 From: "Ed" <ed@edslocomb.com> To: "Peter Jeremy" <PeterJeremy@optushome.com.au> Cc: freebsd-stable@freebsd.org Subject: Re: cpu-timer rate Message-ID: <003b01c5fb87$68ee4690$1132e7d8@robotslave> References: <20051207071710.GQ32006@cirb503493.alcatel.com.au><002b01c5fb24$9a802150$1132e7d8@robotslave> <20051207182236.GS32006@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@optushome.com.au> To: "Ed" <ed@edslocomb.com> 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 "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003b01c5fb87$68ee4690$1132e7d8>