[TIP] Result protocol / problems being solved

Michael Foord fuzzyman at voidspace.org.uk
Tue Apr 14 10:18:36 PDT 2009

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.)


> --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


More information about the testing-in-python mailing list