Erich Schreiber <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list
