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

[Ivan Kokshaysky <ink@jurassic.park.msu.ru>]

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.