Re: [patch] Re: alpha - generic_init_pit - why using RTC for calibration?

Ivan Kokshaysky (ink@jurassic.park.msu.ru)
Fri, 6 Jul 2001 16:00:24 +0400


On Fri, Jul 06, 2001 at 01:03:38PM +0400, Oleg I. Vdovikin wrote:
> return ((long)cc * 1000000) / CALIBRATE_TIME;
>
> truncates the result to the MHZ because of the '* 1000000' statement (cc
> is an int value, so you just loose the precision).

No, this is ok. 'cc' is long here, and CALIBRATE_TIME is in microseconds,
hence '* 1000000'.

> This works ok for x86,
> because x86 uses this value with an accuracy to MHz, but this is not enough
> for Alphas (see gettimeofday - we're relies rpcc for calculation). Try to
> pass 'cycle=666000000' to your kernel and when run ntp - you're out of luck
> for clock sync.

Hmm, this should be ok. I heard of people who had problems with ntp starting
from 0.5% or more difference between real and estimated clock rates.

> But the most innacuracy comes from
>
> #define CALIBRATE_TIME (5 * 1000020/HZ)

With that I agree. All these integer divisions leads to about
%0.02 error.

> (long)(int)0x80000000 != (long)(unsigned int)0x80000000, and
> (long)(int)0x80000000 < 0 and you will get negative frequency value (yes we
> current boxes we're not overflowing, but let's look for the future).

Oh, I see. So you're arguing for 72 vs. 36 GHz limit. ;-)

> Funny?
> ;-))

Not at all. The future of Alpha is dark... [thanks, Compaq!]

> P.S. Ivan, you can reach me by dialing 938-6412 in Moscow.

Ok. And I can be reached at 930-8952.

Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/