> With both variants even on a 166MHz CPU you'll get above 1e-7 precision,
> which is way above accuracy of any crystal oscillator.
No, this is not so - this line
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). 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.
But the most innacuracy comes from
#define CALIBRATE_TIME (5 * 1000020/HZ)
1000020 != CLOCK_TICK_RATE - why? So, with this stuff we're loosing more
than 100 KHz (again, this ok for x86) ....
>
> > has cc's type changed to 'unsigned int' to prevent problems when rpcc
> > overflows.
>
> The only difference is that you'll have extra 'zap' instruction converting
> 'unsigned int' to 'unsigned long'.
No, this is not so. The problem is with the sign bit of int, so,
(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). Funny?
;-))
Oleg.
P.S. Ivan, you can reach me by dialing 938-6412 in Moscow.
-
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/
