linux-kernel - Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 May 2009 10:36:37 +0200
From:	"Ulrich Windl" <ulrich.windl@...uni-regensburg.de>
To:	john stultz <johnstul@...ibm.com>
CC:	ulrich.windl@...uni-regensburg.de, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, Clark Williams <williams@...hat.com>,
	zippel@...ux-m68k.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] tsc_khz= boot option to avoid TSC calibration variance

On 11 May 2009 at 19:12, john stultz wrote:

> All, 
> 
> Despite recent tweaking, TSC calibration variance is still biting users
> who care about keeping close sync with NTP servers over reboots.
> 
> Here's a recent example:
> http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/02061.html
> 
> The problem is, each reboot, we have to calibrate the TSC, and any
> error, regardless of how small, in the calibrated freq has to be
> corrected for by NTP. Assuming the error is within 500ppm NTP can
> correct this, but until it finds the proper correction value for the new
> TSC freq, users may see time offsets from the NTP server.
> 
> In my experience, its fairly easy to see 100khz variance from reboot to
> reboot with 2.6.30-rc.
> 
> While I think its worth trying to improve the calibration further, there
> will likely be a trade-off between very accurate calibration and fast
> boot times.
> 
> To mitigate this, I wanted to provide a tsc_khz= boot option. This would
> allow users to set the tsc_khz value at boot-up, assuming they are
> within 1Mhz of the calibrated value (to protect against bad values).
> Once the tsc_khz value is set in grub, the box will always boot with the
> same value, so the NTP drift value prior to reboot will still be correct
> after rebooting.

[...]

Hi everyone!

I was thinking a little bit on the issue, and I wondered (assuming the TSC 
calibration and the hardware is somewhat stable) whether one should invent a 
mechanism similar to the RTC or random pool; i.e. load the last value that was 
stored or accumulated before. For the TSC calibaration one could build the average 
of previous calibration values (if the value jumps between different numbers).
That would require a sysctl (or equivalent) interface however.

Regards,
Ulrich

--
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/