linux-kernel - Re: [PATCH] Fix TSC calibration issues

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:	Thu, 4 Sep 2008 06:25:42 +0200
From:	Willy Tarreau <w@....eu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Alok Kataria <akataria@...are.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Larry Finger <Larry.Finger@...inger.net>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Michael Buesch <mb@...sch.de>,
	Dan Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Fix TSC calibration issues

On Wed, Sep 03, 2008 at 08:59:05PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 3 Sep 2008, Arjan van de Ven wrote:
> > 
> > but at some point, even doing things in parallel/asynchronous isn't
> > helping, "parallel shit is still shit" :)
> 
> Well, the thing is, you can't call ti "shit" when the fact is that we 
> don't have any other options than to wait.
> 
> The only frequency we can trust on 99% of all machines is the PIT, and 
> it's a very uncomfortable programming model due to all the history (it is 
> one of the few truly 8-bit things left in a modern PC). The other options 
> are just not reliably there, or are known to not have a stable frequency.
> 
> So how would you suggest we do it? Lowering the wait to 5ms (times 5, so 
> it's really 25ms, although we can probably stop early if the first 
> iterations are very consistent) will work, but it _will_ reduce precision. 
> And it's still real time.
> 
> But we simply don't have alternatives. That 'shit' is originally from the 
> company you work for, btw, and while it was good for its time, the 
> replacement (HPET) was horribly misdesigned by the same company, and is 
> deficient in many ways (not the least of which is the idiotic enumeration: 
> another ACPI braindamage), and it often isn't even exposed.
> 
> As a result, the PIT remains to this day the most reliable source of a 
> reference timer. That includes even on really modern machines (ie the one 
> I have from Intel that contains hardware not even released yet!).

15 years ago when I only knew DOS, I used the PIT a lot for precise
delay calculations. I can attest that it can be a very precise timer
for delays when you run busy loops. You even need very few ticks because
you detect the falling edge with a high accuracy. Basically, I would
do this :

    pit1 = readpit();
    while (readpit() == pit1);
    t1 = rdtsc(); // precise beginning of tick 0
    while (readpit() != pit1 - 5000);
    t2 = rdtsc(); // precise beginning of tick 5000

(t2 - t1) will be exactly 5000 PIT ticks long, or 4.1904767 ms.

Additional sanity checks are needed of course, such as rollover
detection, and a max loop counter in case we boot on a machine
with a broken PIT.

If someone wants to test this, I'd be interested in the number of
ticks required to get a good accuracy, I bet that even with a few
hundred ones it's already precise by a few ppm (about the precision
of the input clock in fact).

Willy

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