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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1242167171.3462.13.camel@localhost>
Date:	Tue, 12 May 2009 15:26:11 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Ulrich Windl <ulrich.windl@...uni-regensburg.de>
Cc:	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 Tue, 2009-05-12 at 10:36 +0200, Ulrich Windl wrote:
> 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.

I still feel that a sysctrl or /sys/ interface for this sort of thing is
overkill. It creates yet another interface we have to manage, and really
doesn't improve the situation more then the boot option would.
Additionally it would require quite a bit of work at the clocksource
level to allow for re-calibration (currently we avoid this by
disqualifying the TSC if it changes freq). 

That said, I've gotten very few positive comments from my patch, so I'm
going to give it one more spin (to address Serge's point) and if folks
are still feeling blah about it I'll stop pushing it.

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/