Premature wakeup of time.sleep()

[Nick Craig-Wood]

Erich Schreiber <gmane-esc at mmf.at> wrote:
>  In the Python Library Reference the explanation of the time.sleep()
>  function reads amongst others:
> 
> > The actual suspension time may be less than that requested because 
> > any caught signal will terminate the sleep() following execution 
> > of that signal's catching routine. Also, the suspension time may 
> > be longer than requested by an arbitrary amount because of the 
> > scheduling of other activity in the system.
> 
>  I don't understand the first part of this passage with the premature
>  wakeup. What signals would that be?

If someone sent your process a signal.  Say you pressed CTRL-C - that
generates the INT signal which python translates to the
KeyboardInterrupt exception - and which does interrupt the sleep()
system call.

This probably isn't happening to you though.

>  In the logs I see a about 1% of the wake-up delays beeing negative
>  from -1ms to about -20ms somewhat correlated with the duration of the
>  sleep. 20 minute sleeps tend to wake-up earlier then sub-second
>  sleeps. Can somebody explain this to me? 

Sleep under linux has a granularity of the timer interrupt rate (known
as HZ or jiffies in linux-speak).

Typically this is 100 Hz, which is a granularity of 10ms.  So I'd
expect your sleeps to be no more accurate than +/- 10ms.  +/- 20ms
doesn't seem unreasonable either.

(Linux 2.4 was fond of 100Hz. Its more configurable in 2.6 so could be
1000 Hz. Its likely to be 100 Hz or less in a virtual private server.)

I'm not sure the best way of finding out your HZ, here is one (enter
it all on one line)

start=`grep timer /proc/interrupts | awk '{print $2}'`; sleep 1;
end=`grep timer /proc/interrupts | awk '{print $2}'`; echo $(($end-$start))

Which prints a number about 1000 on my 2.6 machine.

-- 
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick