Matthew> Could this be related to my Noname system clock running
Matthew> slow ?. It would appear the system is missing
Matthew> interupts. Lots of them. I sync the clock twice a day with
Matthew> netdate. Its not uncommon for 3000 second
Matthew> corrections. Other times its just a few seconds..
OK, I can reproduce this when using an IDE drive. It looks like the
IDE driver keeps interrupts disabled for long periods of time. If I
compile a kernel, it looses about 0.06 seconds/second (or about 61
interrupts per second). If the system is idle (save for occasional
background activity), it looses only about 0.001 seconds/second.
The quick & dirty fix: do
hdparm -u 1 /dev/hd?
for each of the IDE drives in your system. This will configure the
IDE driver to reenable interrupts as quickly as possible. This option
is labeled "dangerous", but I was able to do a kernel compile without
any ill effects and from reading the sources, it looks like it should
be save except for old/broken IDE interfaces (and those probably
became extinct even before the Alpha era...).
The real fix is to either disallow drivers to disable clock interrupts
(a solution Linus doesn't like, AFAIK) or to use the Alpha's cycle
counter to detect lost interrupts. The important thing in the latter
solution is that it's not OK to use the cycle counter *instead* of the
timer interrupt since the timer interrupt is derived from the
real-time clock, which presumably has much better long-term stability
than the crystal generating the CPU clock.
Feedback welcome.
--david