lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 21 May 2010 19:03:16 -0700 From: john stultz <johnstul@...ibm.com> To: Brian Bloniarz <bmb@...enacr.com> Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, Andi Kleen <andi@...stfloor.org>, "H. Peter Anvin" <hpa@...or.com>, Dan Magenheimer <dan.magenheimer@...cle.com>, Arjan van de Ven <arjan@...radead.org>, Venkatesh Pallipadi <venki@...gle.com>, chris.mason@...cle.com, linux-kernel@...r.kernel.org Subject: Re: [PATCH] x86: Export tsc related information in sysfs On Thu, May 20, 2010 at 12:19 PM, Brian Bloniarz <bmb@...enacr.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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists