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]
Message-ID: <4A095139.30347.48783F@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ