linux-kernel - Re: [PATCH] x86: Export tsc related information in sysfs

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:	Wed, 26 May 2010 14:44:59 -0400
From:	Brian Bloniarz <bmb@...enacr.com>
To:	john stultz <johnstul@...ibm.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	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 05/26/2010 12:25 PM, john stultz wrote:
> Brian: is this something the NTPd folks actually want? Has anyone
> checked with them before we hand down the solution from high upon on
> lkml mountain?

I haven't checked, it's been a while since I dealt with
this problem. The NTP maintainers definitely complain about the
quick TSC calibration code like it's a bug:
(e.g. http://www.mail-archive.com/questions@lists.ntp.org/msg02079.html).
Anyway I'll reach out before I spend any time investing in
a solution that they don't want (and you don't like :).

> Personally I think NTPd should be a little more savvy about how far it
> trusts the drift file when it starts up. Since I believe its
> fast-startup mode can quickly estimate the drift well within 100ppm,
> which is about the maximum variance I've seen from the calibration code.

The workaround we went with was to remove the drift file on 
every reboot. But in our experience, even with iburst, converging takes
a long time. I don't have hard numbers since it's been a long time since
I investigated the problem, but we defined failure as >1ms offset syncing
to a server in our LAN, and a cold NTP boot takes 10-20 hours to get
there.

I was hoping that being able to reuse the drift information
across boots would shorten convergence time. I think that in principle
it's a nice thing to be able to do. Though as far as I'm aware, neither
chrony nor PTPd (IEEE 1588) attempts to do this.
--
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/