linux-kernel - Re: Fwd: [GIT PULL] timer changes for v3.10

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: <20130507213142.GA10061@amd.pavel.ucw.cz>
Date:	Tue, 7 May 2013 23:31:42 +0200
From:	Pavel Machek <pavel@....cz>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Ingo Molnar <mingo@...nel.org>, Feng Tang <feng.tang@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Fwd: [GIT PULL] timer changes for v3.10

On Tue 2013-05-07 09:01:36, John Stultz wrote:
> On 05/06/2013 11:53 PM, Ingo Molnar wrote:
> >* Feng Tang <feng.tang@...el.com> wrote:
> >
> >>>is even worse than that. Machine can stay is s2ram for weeks (for a
> >>>lot more if it is desktop and you do s2ram for powersaving). Also
> >>>temperature of CPU varies a lot between active and s2ram states. Is
> >>>TSC good enough?
> >>Yes, I think it is relatively precise. Per our test, system time backed
> >>by the S3 non stop TSC only has 1 second drift after 4 days running
> >>(with mixed running and S3 states). And before using this feature, we've
> >>seen many time drift problems due to the RTC HW or system FW with our
> >>platforms.
> >Nice result ...
> >
> >Is that with NTP running?
> >
> >Without NTP, the TSC fast-calibration on bootup is not (expected to be)
> >nearly as precise as the 1:345600 precision you've measured.
> 
> We also do refined calibration now on the TSC asynchronously over a
> period of seconds at boot up that gives us much better accuracy then
> the fast calibration. This helps provide much more consistent
> boot-to-boot TSC frequencies.

On android (and this is targetted at android, right?) system is going
to suspend basically as soon as it boots. Will refined calibration
have enough time to do its job?

And... reason for all this is that RTC has one second granularity when
accessed naively. But surely we could poll RTC X times a second,
getting error down by factor of X?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/