[ntp:questions] Re: linux system clock egregiously slow!

David L. Mills mills at udel.edu
Thu Jan 22 05:43:23 UTC 2004


David,

30 PPM is quite good, almost as good as the Alpha, which is best on the
planet. The procedure I suggested would allow a definitive measurement,
even if something broke in the documentation or implementation.

Dave

David Wuertele wrote:
> 
> Thank you very much for the advice.
> 
> DLM> You might be able to discipline the TOY chip, but I bet it
> DLM> counts only the seconds, which would also be a showstopper.
> 
> Yes, the board RTC chip only counts seconds.  Is there some reason I
> can't use it to discipline the kernel clock?
> 
> DLM> And, surely you don't want the shared memory driver if the TOY
> DLM> chip can be read directly via a register.
> 
> Yes, I realized that as soon as I started actually writing a reference
> clock driver, which turned out to be really easy. :-)
> 
> DLM> Your code suggests MIPS has a process cycle counter
> 
> Yes.
> 
> DLM> If it does have a PCC and the jitter.c program shows no
> DLM> discontinuity, rejoice; the 800-PPM lurch is probably due to a
> DLM> broken initialization constant cycles_per_jiffy.
> 
> Ah.  cycles_per_jiffy = mips_counter_frequency / HZ;
> And  mips_counter_frequency is set as follows:
> 
> 0.  turn off interrupts
> 1.  make sure the MIPS real-time clock is running
> 2.  store the 32-bit number "270,000,000" (ten seconds) into countdown
>     timer #5
> 3.  store zero into the program cycle counter
> 4.  loop while timer #5 > 270,000,000 minus 2,700,000 (.1 seconds)
> 5.  read back the program cycle counter: that is the number of cycles
>     in .1 seconds
> 
> mips_counter_frequency = (number of cycles in .1 seconds) * 10
> 
> How does this rate as far as getting a correct cycles_per_jiffy?  My
> crystal is spec'd accurate to 30PPM, so it seems like my
> cycles_per_jiffy should be pretty close to 30PPM, right?
> 
> Dave



More information about the questions mailing list