[TIP] Result protocol / problems being solved

[Michael Foord]

Scott David Daniels wrote:
> Mark Sienkiewicz wrote:
>   
>> Scott David Daniels wrote:
>>   
>>     
>>> On Windows, time.clock() has higher precision than time.time()
>>> It returns ime in seconds (so is in some sense compatible), but uses a 
>>> counter
>>> that doesn't get time adjustment the way the date & time-of-day do
>>> (time.time() has better synchronization with the atomic clock, but at
>>> the cost of local adjustments.  If your timing interval covers one of those
>>> adjustments, the timing on that measurement will be mis-measured (and
>>> may even be negative). 
>>>     
>>>       
>> Wait a minute --- the only way I can see that it could be negative is if 
>> stop_time < start_time.  Are you saying that time can actually run 
>> _backwards_ on Windows?
>>   
>>     
> I think it can, but don't have a verified sighting to guarantee so.  I 
> have in the past had timing
> messed up in a way that led me to unplug the internet for certain 
> measurements.  And a big
> ":-)" to jnoller for his comment.
>   

If you have twin core AMD processors and haven't applied a specific 
Windows hotfix then calls to the underlying OS time functionality can 
occasionally  report that time has gone backwards... (I've seen this 
when doing profiling.)

Michael

> --Scott David Daniels
> Scott.Daniels at Acm.Org
>
>
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog