Re: time drift and fb comsole activity

[Cort Dougan]

We have the same trouble on PPC but we make sure to re-sync on each
interrupt.  We can see several lost timer interrupts after a ^L in emacs
running on the fb console.  The resync lets us catch up on those interrupts
(and not lose time) but we still spend a lot of time not servicing
interrupts.

Does x86 not resync on timer interrupts?

} Eric Buddington wrote:
} > 
} > I know this has been reported on the list recently, but I think I can
} > provide better detail. I'm running 2.4.2 with atyfb on a K6-2/266
} > running at 250. This system has no history of clock problems.
} > 
} > adjtimex-1.12 --compare gives me "2nd diff" readings of -0.01 in quiescent
} > conditions.
} > 
} > flipping consoles rapidly cboosts this number to -3 or -4.
} > 
} > catting the full documentation to ntpd (seemed appropriate) gives me
} > "2nd diff" numbers a little over 34. If I read the numbers correctly,
} > 47 seconds of CMOS time passed while the system clock only passed 13
} > seconds.
} > 
} > The processor and the CMOS clock were moving at zero velocity relative
} > to each other, and were both in normal Earth gravity.
} 
} The kernel blocks interrupts during console output.  fbdev
} consoles are slow.  Net result: many lost timer interrupts.
} 
} I'm working on it.  Slowly.  Should have something next week.