Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752779AbYJBBZ4 (ORCPT ); Wed, 1 Oct 2008 21:25:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751484AbYJBBZr (ORCPT ); Wed, 1 Oct 2008 21:25:47 -0400 Received: from terminus.zytor.com ([198.137.202.10]:41851 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbYJBBZq (ORCPT ); Wed, 1 Oct 2008 21:25:46 -0400 Message-ID: <48E42234.9000808@zytor.com> Date: Wed, 01 Oct 2008 18:21:56 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Zachary Amsden CC: Anthony Liguori , Jeremy Fitzhardinge , Alok Kataria , "avi@redhat.com" , Rusty Russell , Gerd Hoffmann , Ingo Molnar , the arch/x86 maintainers , LKML , "Nakajima, Jun" , Daniel Hecht , "virtualization@lists.linux-foundation.org" , "kvm@vger.kernel.org" Subject: Re: [RFC] CPUID usage for interaction between Hypervisors and Linux. References: <1222881242.9381.17.camel@alok-dev1> <48E3BBC1.2050607@goop.org> <1222894878.9381.63.camel@alok-dev1> <48E3E8DE.1080602@goop.org> <48E3ECD1.30809@codemonkey.ws> <1222904824.7330.83.camel@bodhitayantram.eng.vmware.com> <48E4183A.7090208@zytor.com> <1222909900.7330.106.camel@bodhitayantram.eng.vmware.com> In-Reply-To: <1222909900.7330.106.camel@bodhitayantram.eng.vmware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2070 Lines: 46 Zachary Amsden wrote: > > I'm not suggesting using the nominal value. I'm suggesting the > measurement be done in the one and only place where there is perfect > control of the system, the processor boot-strapping in the BIOS. > > Only the platform designers themselves know the speed of the oscillator > which is modulating the clock and so only they should be calibrating the > speed of the TSC. > No. *Noone*, including the manufacturers, know the speed of the oscillator which is modulating the clock. What you have to do is average over a timespan which is long enough that the SSM averages out (a relatively small fraction of a second.) As for trusting the BIOS on this, that's a total joke. Firmware vendors can't get the most basic details right. > If this modulation really does alter the frequency by +/- 2% (seems high > to me, but hey, I don't design motherboards), using an LFO, then > basically all the calibration done in Linux is broken and has been for > some time. You can't calibrate only once, or risk being off by 2%, you > can't calibrate repeatedly and take the fastest estimate, or you are off > by 2%, and you can't calibrate repeatedly and take the average without > risking SMI noise affecting the lowest clock speed measurement, > contributing unknown error. You have to calibrate over a sample interval long enough that the SSM averages out. > Hmm. Re-reading your e-mail, I see you are saying the nominal frequency > may be off by 2% (and I easily believe that), not necessarily that the > frequency modulation may be 2% (which I still think is high). Does > anyone know what the actual bounds on spread spectrum modulation are or > how fast the clock is modulated? No, I'm saying the frequency modulation may be up to 2%. Typically it is something like [-2%,+0%]. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/