Re: [PATCH] Fix TSC calibration issues

[Willy Tarreau]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/