time.clock() going backwards??

[Tim Roberts]

"Tim Peters" <tim.peters at gmail.com> wrote:

>[Giovanni Bajo[
>>> I experimented something very strange, a few days ago. I was debugging an
>>> application at a customer's site, and the problem turned out to be that
>>> time.clock() was going "backwards", that is it was sometimes
>>> (randomically) returning a floating point value which was "less than" the
>>> value returned by the previous invokation. The computer was a pretty fast
>>> one (P4 3Ghz I think, running Windows XP), and this happened only between
>>> very close invokations of time.clock().
>
>[Terry Reed]
>> I seem to remember this being mentioned before on the list, perhaps by Tim
>> Peters.  Perhaps he will chime in.
>
>No real need ;-)  BIOS or HAL bug on a multiprocessor (or maybe even
>hyperthreaded) box is by far the most likely cause (and the only cause
>ever identified for sure by people who followed up).  Python's C code
>slinging QueryPerformanceCounter is exceedingly simple, and isn't a
>suspect because of that.  It's on the edge of vague possibility that
>Microsoft's compiler generates non-monotonic code for converting
>64-bit integer to double:

It is much simpler than that.  With a multiprocessor HAL, including on a
dual-core or hyperthreaded system, QueryPerformanceCounter returns the raw
cycle counter (RDTSC).  However, on Windows XP, the operating system does
not synchronize the cycle counters on multiple processors, and they can be
actually be millions of cycles apart.

This was a change from previous systems.  On NT4 and Win2000, the operating
actually rewrote the cycle counters on the second (and beyond) processors
to align them to the first processor, so the delta was usually only a dozen
or two cycles.  XP does not appear to do that.  I think that is a huge
mistake, since it renders QueryPerformanceCounter non-monotonic.
-- 
- Tim Roberts, timr at probo.com
  Providenza & Boekelheide, Inc.