x86: Export tsc related information in sysfs
in [Kernel]
|
From: john stultz on 21 May 2010 22:10 On Thu, May 20, 2010 at 12:19 PM, Brian Bloniarz <bmb(a)athenacr.com> wrote: > Take NTP as an example. It does a pretty good job of observing the drift in > gettimeofday() against a reference clock and correcting for it. This seems > to work well even when GTOD uses the TSC. But, it assumes that the drift > changes slowly. > > That goes out the window on reboot, because the kernel only spends 25ms on > TSC<->PIT calibration and the value of tsc_khz can vary a lot from boot to > boot. Then NTP starts up and reads a drift value from /var/lib/ntp/ntp.drift > that it *thinks* is accurate. In our experience, it'll then spend up to 48 > hours doing god knows what to the clock until it converges on the real > drift at the new tsc_khz. �initscripts could correct for the kernel's > recalibration, but tsc_khz isn't exported. > > So it's too bad that it can't be exported somehow. The TSC on our > machines has proven to be stable for all intents and purposes; I just > checked 25 of my machines, most have uptime of >200 days, all of them > still have current_clocksource=tsc. After NTP or PTPd has been running > for a while, things converge, but being unable to reboot is a headache. > Using the HPET for gettimeofday() would be impractical for performance > reasons. Yea, the relative instability of the tsc calibration at boot is an issue for folks who want very very precise timekeeping immediately after a reboot. I proposed a solution to this awhile back via a boot option users could use to specify the tsc_khz freq, so it would be consistent from boot to boot. See: https://patchwork.kernel.org/patch/22492/ It didn't really go anywhere due to a lack of public interest. However, if you're interested in playing with it, I can try to revive the patch. 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 21 May 2010 23:40 On 05/21/2010 07:03 PM, john stultz wrote: > > Yea, the relative instability of the tsc calibration at boot is an > issue for folks who want very very precise timekeeping immediately > after a reboot. > > I proposed a solution to this awhile back via a boot option users > could use to specify the tsc_khz freq, so it would be consistent from > boot to boot. See: https://patchwork.kernel.org/patch/22492/ > > It didn't really go anywhere due to a lack of public interest. > However, if you're interested in playing with it, I can try to revive > the patch. > The point about NTP is a very good one; with NTP you *really* want what you're adjusting to be directly related to the crystal oscillator -- as what it is; precision over accuracy as NTP takes care of accuracy but not precision. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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 14:20 > From: john stultz [mailto:johnstul(a)us.ibm.com] > > Yea, the relative instability of the tsc calibration at boot is an > issue for folks who want very very precise timekeeping immediately > after a reboot. > > I proposed a solution to this awhile back via a boot option users > could use to specify the tsc_khz freq, so it would be consistent from > boot to boot. See: https://patchwork.kernel.org/patch/22492/ > > It didn't really go anywhere due to a lack of public interest. > However, if you're interested in playing with it, I can try to revive > the patch. Another possibility: Optionally trust the stamped rate for the part? I understand that on Nehalem this value is available in MSR_PLATFORM_INFO[15:8] (google for MSR_PLATFORM_INFO 15 8), but I don't know if this MSR is available on older (or AMD) processors. Just wondering: If one were to put an ultra-precise scope on a processor, how far off would the calibrated value be? I'd imagine the process of calibrating one unknown crystal against a second crystal which has a known-but-not-highly-precise frequency, though good enough for most purposes, is not particularly accurate. In other words, maybe the stamped rate is more accurate than the calibrated rate anyway? -- 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 14:30 On 05/24/2010 11:13 AM, Dan Magenheimer wrote: > Just wondering: If one were to put an ultra-precise scope on > a processor, how far off would the calibrated value be? I'd > imagine the process of calibrating one unknown crystal against > a second crystal which has a known-but-not-highly-precise > frequency, though good enough for most purposes, is not particularly > accurate. In other words, maybe the stamped rate is more accurate > than the calibrated rate anyway? No. Not even close. A spread-spectrum clock is inaccurate by entire percentage points. A non-spread clock is typically �50 ppm with typical consumer PC oscillators, �1 ppm with non-crappy but still cheap oscillators (e.g. used in cell phones.) -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 15:00
On Mon, 2010-05-24 at 11:13 -0700, Dan Magenheimer wrote: > > From: john stultz [mailto:johnstul(a)us.ibm.com] > > > > Yea, the relative instability of the tsc calibration at boot is an > > issue for folks who want very very precise timekeeping immediately > > after a reboot. > > > > I proposed a solution to this awhile back via a boot option users > > could use to specify the tsc_khz freq, so it would be consistent from > > boot to boot. See: https://patchwork.kernel.org/patch/22492/ > > > > It didn't really go anywhere due to a lack of public interest. > > However, if you're interested in playing with it, I can try to revive > > the patch. > > Another possibility: Optionally trust the stamped rate for the part? > > I understand that on Nehalem this value is available in > MSR_PLATFORM_INFO[15:8] (google for MSR_PLATFORM_INFO 15 8), > but I don't know if this MSR is available on older (or AMD) > processors. 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. 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/ |