slow tick when idle

[Bruce Evans]

On Wed, 3 Jun 2009, Barney Wolff wrote:

> I have an odd problem with wait timing.  When the system is quite busy,
> for example doing multiple port builds, waits in select() or sleep()
> work fine.  But when the system is otherwise mostly idle, waits run
> at least 2.5% slow.  This happens on both a 6-stable from 12/08 and
> 7-stable from 5/28/09, and whether I use ACPI-fast or HPET.  Time of
> day is not affected, only waits.

Timeouts are implemented using hardclock() interrupts, so they would
take longer than expected if some of these interrupts are missed.
nanosleep() shouldn't notice the effect of small errors in the hardclock()
interrupt frequency (which will become large absolute errors for long
waits), but it is misimplemented.  (The worst-case error with a working
i386 i8254 timer and HZ = 1000 is about 0.1% or 3.6 seconds per hour.)
nansleep() should wake up about 0.1% early to handle the case where
the clock runs slow.  (If the clock runs fast then it already wakes
up early.  It already knows to go back to sleep then, so it only needs
a small change to avoid late wakeups.)  To handle your clock, it would
have to wake up 2.5% early.

> My machine is a Dell XPS410 with Intel Core2 2.13GHz, 2 cores.  The
> problem does not occur on an older single-cpu Athlon XP with 7.2-rel.
>
> Perhaps some artifact of cpu state under light load?

Your hardclock timer is probably the lapic.  This has more delicate
interactions with sleep states than the i8254 (I think that since the
i8254 is old and often used for timeouts, hardware designers know not
to stop it for low sleep states.)  Normally when there is this problem,
the lapic timer stops completely and waits would be infinite, except
other interrupt activity (like dancing on the keyboard) wakes up the
system enough for some lapic interrupts to get through, and timeouts
are only delayed for several thousand percent.  I don't know of any
bugs that result in only 2.5% of lapic interrupts not getting through.

Bruce