Tony Nelson wrote:
> In article <[EMAIL PROTECTED]>,
> Claudio Grondi <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
