time.sleep(1) sometimes runs for 200 seconds under windows

[Claudio Grondi]

Tony Nelson wrote:
> In article <dtqpkl$kbo$1 at newsreader3.netcologne.de>,
>  Claudio Grondi <claudio.grondi at freenet.de> wrote:
> 
> 
>>Claudio Grondi wrote:
>>
>>>Claudio Grondi wrote:
>>>
>>>
>>>>Paul Probert wrote:
>>>>
>>>>
>>>>>Peter Hansen wrote:
>>>>>
>>>>>
>>>>>>Are you saying that you believe the time.sleep(1) call is actually 
>>>>>>blocking for 200 seconds?
>>>>
>>>>With such rare occurrence it is very hard to tell what is going on. 
>>>>Usually I put such strange things on a list of curiosities I don't 
>>>>want to know the reason of, because it is in my eyes not worth the 
>>>>effort. Maybe it is even a common problem not yet detected by me, 
>>>>because I have never run this kind of tests for such a long time.
>>>>Starting today, I can tell you statistically not earlier than in one 
>>>>week, if I have the same problem on my machines (currently I am 
>>>>running only one or two at the same time).
>>>
>>>
>>>Here the intermediate results on my Windows XP machine connected to the 
>>>Internet via very fast digital phone line connection (network 
>>>card/digital-converter box/phone-line):
>>>
>>>dt= 1.125          time= 2006_02_24_11h_36m_15s
>>>dt= 9.20200014114  time= 2006_02_24_12h_46m_49s
>>>dt= 1.18799996376  time= 2006_02_24_14h_43m_32s
>>>
>>>The code used:
>>>"""
>>>import time
>>>while True:
>>>  oldtime=time.time()
>>>  time.sleep(1.0)
>>>  newtime=time.time()
>>>  dt=newtime-oldtime
>>>  if dt > 1.1:
>>>    print 'dt=',dt,' time=',time.strftime('%Y_%m_%d_%Hh_%Mm_%Ss')
>>>"""
>>>running in a command line console parallel to usual daily business on 
>>>the computer.
>>>
>>>The yesterday night run (5 hours) gave max. 1.125 sec., so I am 
>>>surprized to see the 9 seconds already after only two hours today.
>>>
>>>Claudio
>>
>>The 9.2 seconds difference was also because of time synchronization 
>>Windows XP does using time.windows.com server - it reported to be done 
>>last time 2006-02-24 at 12:46 o'clock i.e. exactly at the same time 
>>where the 9.2 delay occurred.
> 
> 
> ISTM that using time-of-day is the wrong thing for measuring elapsed 
> time, but I don't find anything in the time module that would be better.  
> /proc/uptime looks like it would work on linux, in a roundabout way:
> 
>     >>> up = open('/proc/uptime')
>     >>> up.seek(0) ; up.read()
> 
> will print uptime and idle time, but on linux only.  At least it seems 
> to be fast enough for the purpose at hand (about 18 microseconds on my 
> old box, according to timeit).
> 
> Is there a better timer available in python?  I see that timeit module 
> uses time.time() (or time.clock() on MSWindows), so I am not hopeful.

I mean, that using time.clock() solves the problem, because the output 
of the following code:

"""
import time
while True:
   old_Time = time.time()
   oldClock = time.clock()
   time.sleep(1.0)
   new_Time = time.time()
   newClock = time.clock()
   dt=new_Time-old_Time
   if(  dt < 0.9 or dt > 1.1 ):
     print 'new_Time-old_Time =', dt,' 
time=',time.strftime('%Y_%m_%d_%Hh_%Mm_%Ss')
     print 'newClock-oldClock =', newClock-oldClock
"""

was:

new_Time-old_Time = 177.921999931  time= 2006_02_26_20h_46m_01s
newClock-oldClock = 0.999994692063
new_Time-old_Time = -124.171999931  time= 2006_02_26_20h_44m_19s
newClock-oldClock = 1.00000502857
new_Time-old_Time = 53.3339998722  time= 2006_02_26_20h_45m_42s
newClock-oldClock = 1.00001313016
new_Time-old_Time = 0.634000062943  time= 2006_02_26_20h_45m_48s
newClock-oldClock = 1.00000195556

where I have manipulated the system clock manually to trigger the output.

Claudio