I've modified time.c like this
/* If the given value is within 1% of what we calculated,
accept it. Otherwise, use what we found. */
cycle_freq = hwrpb->cycle_freq;
< one_percent = cycle_freq / 100;
> one_percent = cycle_freq / 10000;
Almost always ignore hwrpb->cycle_freq
and works much better. Allowing 1% means 864sec error/day.
I think comparing hwrpb->cycle_freq and calculated one is
meaningless, It's like saying "measured value can be wrong".
And it means using rpcc can also be wrong.
Anyway differences btw. hwrpb and estimated were
599769920 - 598802395 = 967525 0.16%
699300699 - 698843222 = 457477 0.06%
751879699 - 749712100 = 2167599 0.2%
I thought alpha has different archtecture.
A company hw designer said nautilus has 100MHz base clock and
CPU clock is multiple of that. And, unfortunately,
I have DP264 with 500MHz CPU and it's cpuinfo looks
cycle frequency [Hz] : 500000000
platform string : AlphaPC 264DP 500 MHz
The system is being up for more than a month and clock is accurate.
Perfect~!
So I guessed It's different from PC, they are not multiple of
33.333333, CPU clock is well rounded so 699300699 is a wrong one.
Anyway we still have chance to get 8.6sec error/day,
and there's measurement error usually 2000 counts btw min and max.
So why don't we synch with cmos clock once a day or so?
If we can't trust cmos then measuring cycle frequency
based on cmos is meaningless. Let LX alone.
Soohoon.
-----Original Message-----
From: Richard Henderson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 22, 2000 6:43 PM
To: Soohoon Lee
Cc: Software; Ruth Shelley; '[EMAIL PROTECTED]'
Subject: Re: Alpha clock problem
On Thu, Apr 20, 2000 at 11:27:56PM -0400, Soohoon Lee wrote:
> Here's an example.
> CPU clock is 700MHz but /proc/cpuinfo reports
>
> cycle frequency [Hz] : 699300699
> platform string : API UP1000 699 MHz
>
> the freq. must be 700000000 so diff. btw those two are
> 700000000 - 699300699 = 699301
> approx. 700000 error per sec. it's
> 700000/700000000 = 0.001sec error/sec
> 0.001 * 24 * 60 * 60 = 86.400 sec errir/day.
So you're asserting that your CPU's crystal runs at *exactly* 700MHz?
You assert that there is no variance in the manufacturing process?
Have you hooked that crystal up to an osciliscope (or other analysis
tool) to see that the actual frequency of that crystal is closer to
700MHz than to 699.3MHz?
> I think we cannot measure the frequency accurately always.
Perhaps not, but there's very little else we can do I'm afraid.
> So what about rounding off the frequency count?
That would almost certainly do more harm than good.
r~
