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

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

Date:	Mon, 24 May 2010 14:26:01 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	john stultz <johnstul@...ibm.com>
CC:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Brian Bloniarz <bmb@...enacr.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/24/2010 01:39 PM, john stultz wrote:
> On Mon, 2010-05-24 at 13:20 -0700, H. Peter Anvin wrote:
>> On 05/24/2010 11:51 AM, john stultz wrote:
>>>
>>> Hmmm. That could be an option for newer cpus that I wouldn't oppose.
>>>
>>> While Peter is correct that the stamped value is probably not very
>>> accurate, atleast it would be constant from boot to boot, and NTP's
>>> calculated drift value would be correct. 
>>>
>>> We'd need a check to make sure its not way off, since NTP will give up
>>> if its outside 500ppm.  So as long as its close to the calibrated value,
>>> we probably could use it.
>>>
>>
>> Is that still the case?  I thought newer versions of NTP could deal with
>> large values.  Inaccuracies of way more than 500 ppm are everyday.
> 
> That's scary. 
> 
> Yea, in the kernel the ntp freq correction tops out at 500ppm. Almost
> all the systems I see tend to fall in the +/- 200ppm range (if there's
> not something terribly wrong with the hardware).
> 
> So maybe things aren't so bad out there? Or is that wishful thinking?
> 

In the kernel, yes; I thought the ntp daemon itself now handled the
exceptions (basically it detects if the PLL consistently veers off the
rails and adjusts the timing constants.)

However, you're comparing apples to oranges: you're talking about
current kernels, which means a calibrated TSC, which means you're
comparing to the non-spread 14.31818 MHz clock (which feeds into the
HPET, PMTMR and 8254 on a standard PC platform.)  In most PCs this is a
separate oscillator from the bus clock which is spread spectrum.  As a
result, it should be in the ±50 ppm range in theory; in practice as you
observe the range is wider.

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