[ntp:questions] Re: linux system clock egregiously slow!
dave-gnus at bfnet.com
Wed Jan 21 18:06:49 UTC 2004
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
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
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?
More information about the questions