Thank you every body for your comments.
Especially Jeff Epler for your hint about NTP. You're right. I see a
(constant but somewhat huge)time drift of about 1 ms/min which I can
correct for.
Thank you Steve Horsley for the clarification of the interrupts that
would end the delay. I didn't think
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
On Mon, 12 Sep 2005 19:33:07 -0400, Peter Hansen [EMAIL PROTECTED] wrote:
Steve Horsley wrote:
I think the sleep times are quantised to the granularity of the system
clock, shich varies from os to os. From memory, windows 95 has a 55mS
timer, NT is less (19mS?), Linux and solaris 1mS. All
Bengt Richter wrote:
On Mon, 12 Sep 2005 19:33:07 -0400, Peter Hansen [EMAIL PROTECTED] wrote:
Steve Horsley wrote:
I think the sleep times are quantised to the granularity of the system
clock, shich varies from os to os. From memory, windows 95 has a 55mS
timer, NT is less (19mS?), Linux
Is your system running something like ntpd? I'm not sure how use of
ntp, which will slowly adjust the system's time to match the network
time, will interact with calls to sleep().
This is almost certainly an OS question, though, not a Python question.
Python's time.sleep() is a bit complicated,
Erich Schreiber 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.
Steve Horsley wrote:
I think the sleep times are quantised to the granularity of the system
clock, shich varies from os to os. From memory, windows 95 has a 55mS
timer, NT is less (19mS?), Linux and solaris 1mS. All this is from
For the record, the correct value for NT/XP family is about
