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/