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

David L. Mills mills at udel.edu
Wed Jan 21 03:19:45 UTC 2004


David,

The jitter.c program in the ./util directory in the distribution was
designed to look for discontinuities due to missed timer interrupts,
violations of monotonicity, etc. If you do find lost interrupts, in my
experience (with old VAXen) this is an absolute showstopper.

You might be able to discipline the TOY chip, but I bet it counts only
the seconds, which would also be a showstopper. Even if it has a few
digits below the seconds point and can be disciplined properly,
applilcation programs don't use it, so you are back to disciplining the
kernel clock. And, surely you don't want the shared memory driver if the
TOY chip can be read directly via a register.

Your code suggests MIPS has a process cycle counter, which was certainly
not the case in the Digital Ultrix, which used a MIPS chip. If it does
have a PCC and the jitter.c program shows no discontinuity, rejoice; the
800-PPM lurch is probably due to a broken initialization constant
cycles_per_jiffy.

Configure ntpd with a well behaved source. Put "disable ntp" in the
configuration file. Run the machine for a day or so and use ntpq to see
how the offset diverges. If the jitter.c program shows good and the
offset looks clean and straight, adjust the cycles_per_jiffy to correct
the apparent frequency offset.

Happy chime.

Dave 



David Wuertele wrote:
> 
> I realize this may be off-topic, but I figured the time-heads on this
> list might be better prepared to point me in the right direction than
> on the linux kernel lists...
> 
> I run linux 2.4.18 on an embedded MIPS little-endian CPU, but I'm
> getting distressingly poor system clock performance.  My CPU clock is
> supposed to be good to about 30 PPM, but my system time is always slow
> to the tune of 800 PPM!
> 
> I do a lot of PIO, so I wonder if it is possible that the PIO makes
> the kernel lose timer interrupts?  I notice that my timer is implemented
> as a countdown: in arch/mips/kernel/time.c:timer_interrupt(), it says:
> 
> /*
>  * high-level timer interrupt service routines.  This function
>  * is set as irqaction->handler and is invoked through do_IRQ.
>  */
> void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
> {
>         if (mips_cpu.options & MIPS_CPU_COUNTER) {
>                 unsigned int count;
> 
>                 /*
>                  * The cycle counter is only 32 bit which is good for about
>                  * a minute at current count rates of upto 150MHz or so.
>                  */
>                 count = read_32bit_cp0_register(CP0_COUNT);
>                 timerhi += (count < timerlo);   /* Wrap around */
>                 timerlo = count;
> 
>                 /*
>                  * set up for next timer interrupt - no harm if the machine
>                  * is using another timer interrupt source.
>                  * Note that writing to COMPARE register clears the interrupt
>                  */
>                 write_32bit_cp0_register (CP0_COMPARE,
>                                           count + cycles_per_jiffy);
> 
>         }
> <snip>...
> 
> Does it make sense that the average latency to the
> write_32bit_cp0_register() command would be .8ms?
> 
> I understand that I can use ntpd to correct this problem, but 800PPM
> seems egreggiously bad to me.  Any suggestions are welcome!
> 
> Dave



More information about the questions mailing list