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

[Tony Nelson]

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.
________________________________________________________________________
TonyN.:'                        *firstname*nlsnews at georgea*lastname*.com
      '                                  <http://www.georgeanelson.com/>