Re: x86: Clean up computation of HPET .mult variables

[Carlos R. Mafra]

On Tue  6.May'08 at 19:17:41 -0700, Daniel Walker wrote:
> 
> On Tue, 2008-05-06 at 17:50 -0300, Carlos R. Mafra wrote:
> > so there is no difference at all at this precision level!
> > 
> > Out of curiosity I computed the "exact" value by hand and
> > got 292935555.9 so we can't even talk about "error" because
> > the difference is in the extra digit not considered with
> > the precision I used to print the results.
> > 
> > And if you look at the patch to do computation using 
> > clocksource_hz2mult() you will see that it is uglier
> > than the simple call to div_sc(), as you have to
> > consider an extra variable hpet_freq and do an extra
> > do_div() together with an extra rounding.
> > 
> > So I think you will be ok with the patch now, right? :-)
> 
> Not yet ..

Ok.

> I used you patch with some formatting changes and I get,
> 
> clocksource_hpet.mult   walker = 292935555
> clocksource_hpet.mult my patch = 292935555
> 
> Same as yours .. just checking ;)

Good!

> Now I modify the shift value from 22 to 25 and I get this,
> 
> clocksource_hpet.mult   walker = 2343484437
> clocksource_hpet.mult my patch = 2343484446
> 
> I don't think this is due to rounding .. I'm not really sure why they're
> different .. I would assume the clocksource_hz2mult is more correct, but
> feel free to check into it if you want..

Heh, I trust those numbers because they imply that my patch is good :-)

Note that my hpet_period = 69841279 * 10^{-15} secs, then

mult/2^shift = ns/cyc = 69.841279 <-- period in nanoseconds

so, using Kcalc I get for shift 22 (the "exact" value, no rounding)

mult = 2^22 * 69.841279 = 292,935,555.875

while for shift = 25 I get 8 times that, or

mult = 2,343,484,447

So comparing with the numbers you quoted from your experiments
you will realize that the value you got with my patch is actually
10 times better, so your assumption about clocksource_hz2mult
being more correct is not good.

> The reason I'm messing with the shift is cause 22 is actually too low..
> For your period it can be 25, which would give better accuracy.

Is there some formula to decide which shift value is better to
a given period? IOW, how did you arrive at 25? Note that I
want to learn this, that's why I am asking.

> If you want to check the shift calculation I used it looks like this,

Hmm, it is more complicated than div_sc in my humble opinion.

> static inline u32 clocksource_hz2shift(u32 bits, u32 hz)
> {
>        u64 temp;
> 
>        for (; bits > 0; bits--) {
>                temp = (u64) NSEC_PER_SEC << bits;
>                do_div(temp, hz);
>                if ((temp >> 32) == 0)
>                        break;
>        }
>        return bits;
> }
> 
> Daniel
--
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/