x86: Export tsc related information in sysfs
in [Kernel]
|
From: H. Peter Anvin on 24 May 2010 16:30 On 05/24/2010 11:51 AM, john stultz wrote: > > Hmmm. That could be an option for newer cpus that I wouldn't oppose. > > While Peter is correct that the stamped value is probably not very > accurate, atleast it would be constant from boot to boot, and NTP's > calculated drift value would be correct. > > We'd need a check to make sure its not way off, since NTP will give up > if its outside 500ppm. So as long as its close to the calibrated value, > we probably could use it. > Is that still the case? I thought newer versions of NTP could deal with large values. Inaccuracies of way more than 500 ppm are everyday. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on 24 May 2010 16:40 On Mon, 2010-05-24 at 13:20 -0700, H. Peter Anvin wrote: > On 05/24/2010 11:51 AM, john stultz wrote: > > > > Hmmm. That could be an option for newer cpus that I wouldn't oppose. > > > > While Peter is correct that the stamped value is probably not very > > accurate, atleast it would be constant from boot to boot, and NTP's > > calculated drift value would be correct. > > > > We'd need a check to make sure its not way off, since NTP will give up > > if its outside 500ppm. So as long as its close to the calibrated value, > > we probably could use it. > > > > Is that still the case? I thought newer versions of NTP could deal with > large values. Inaccuracies of way more than 500 ppm are everyday. That's scary. Yea, in the kernel the ntp freq correction tops out at 500ppm. Almost all the systems I see tend to fall in the +/- 200ppm range (if there's not something terribly wrong with the hardware). So maybe things aren't so bad out there? Or is that wishful thinking? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 24 May 2010 17:40 On 05/24/2010 01:39 PM, john stultz wrote: > On Mon, 2010-05-24 at 13:20 -0700, H. Peter Anvin wrote: >> On 05/24/2010 11:51 AM, john stultz wrote: >>> >>> Hmmm. That could be an option for newer cpus that I wouldn't oppose. >>> >>> While Peter is correct that the stamped value is probably not very >>> accurate, atleast it would be constant from boot to boot, and NTP's >>> calculated drift value would be correct. >>> >>> We'd need a check to make sure its not way off, since NTP will give up >>> if its outside 500ppm. So as long as its close to the calibrated value, >>> we probably could use it. >>> >> >> Is that still the case? I thought newer versions of NTP could deal with >> large values. Inaccuracies of way more than 500 ppm are everyday. > > That's scary. > > Yea, in the kernel the ntp freq correction tops out at 500ppm. Almost > all the systems I see tend to fall in the +/- 200ppm range (if there's > not something terribly wrong with the hardware). > > So maybe things aren't so bad out there? Or is that wishful thinking? > In the kernel, yes; I thought the ntp daemon itself now handled the exceptions (basically it detects if the PLL consistently veers off the rails and adjusts the timing constants.) However, you're comparing apples to oranges: you're talking about current kernels, which means a calibrated TSC, which means you're comparing to the non-spread 14.31818 MHz clock (which feeds into the HPET, PMTMR and 8254 on a standard PC platform.) In most PCs this is a separate oscillator from the bus clock which is spread spectrum. As a result, it should be in the ±50 ppm range in theory; in practice as you observe the range is wider. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on 24 May 2010 18:10 > > Is that still the case? I thought newer versions of NTP could deal > with > > large values. Inaccuracies of way more than 500 ppm are everyday. > > That's scary. > > Yea, in the kernel the ntp freq correction tops out at 500ppm. Almost > all the systems I see tend to fall in the +/- 200ppm range (if there's > not something terribly wrong with the hardware). > > So maybe things aren't so bad out there? Or is that wishful thinking? Since Brian's concern is at boot-time at which point there is no network or ntp, and assuming that it would be unwise to vary tsc_khz dynamically on a clocksource==tsc machine (is it?), would optionally lengthening the TSC<->PIT calibration beyond 25ms result in a more consistent tsc_khz between boots? Or is the relative instability an unavoidable result of skew between the PIT and the fixed constant PIT_TICK_RATE combined with algorithmic/arithmetic error? Or is the jitter of the (spread-spectrum) TSC too extreme? Or ??? If better more consistent calibration is possible, offering that as an optional kernel parameter seems better than specifying a fixed tsc_khz (stamped or user-specified) which may or may not be ignored due to "too different from measured tsc_khz". Even an (*optional*) extra second or two of boot time might be perfectly OK if it resulted in an additional five or six bits of tsc_khz precision. Thoughts, Brian? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 24 May 2010 18:40
On 05/24/2010 03:04 PM, Dan Magenheimer wrote: >>> Is that still the case? I thought newer versions of NTP could deal >> with >>> large values. Inaccuracies of way more than 500 ppm are everyday. >> >> That's scary. >> >> Yea, in the kernel the ntp freq correction tops out at 500ppm. Almost >> all the systems I see tend to fall in the +/- 200ppm range (if there's >> not something terribly wrong with the hardware). >> >> So maybe things aren't so bad out there? Or is that wishful thinking? > > Since Brian's concern is at boot-time at which point there is no > network or ntp, and assuming that it would be unwise to vary tsc_khz > dynamically on a clocksource==tsc machine (is it?), would optionally > lengthening the TSC<->PIT calibration beyond 25ms result in a more > consistent tsc_khz between boots? Or is the relative instability > an unavoidable result of skew between the PIT and the fixed constant > PIT_TICK_RATE combined with algorithmic/arithmetic error? Or is > the jitter of the (spread-spectrum) TSC too extreme? Or ??? > > If better more consistent calibration is possible, offering > that as an optional kernel parameter seems better than specifying > a fixed tsc_khz (stamped or user-specified) which may or may > not be ignored due to "too different from measured tsc_khz". > Even an (*optional*) extra second or two of boot time might > be perfectly OK if it resulted in an additional five or six > bits of tsc_khz precision. > > Thoughts, Brian? Making the calibration time longer should give a more precise result, but of course at the expense of longer boot time. A longer sample would make sense if the goal is to freeze it into a kernel command line variable, but the real question is how many people would actually do that (and how many people would then suffer problems because they upgraded their CPU/mobo and got massive failures on post-boot.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |