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