time.clock() going backwards??

[Claudio Grondi]

Rob Williscroft wrote:
> Claudio Grondi wrote in news:ecu546$sn9$1 at newsreader2.netcologne.de in
> gmane.comp.python.general: 
> 
> 
>>Tim Roberts wrote:
>>
>>>"Tim Peters" <tim.peters at gmail.com> wrote:
> 
> 
>>>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. 
>>
>>How does it come, that processors on same mainboard run at different 
>>speeds? Do they have separate clock-pulse generators?
> 
> 
> I don't see any claim above that they run at different speeds, only 
> that the counters are several million cycles apart, IOW running at the 
> same speed but with different initial values, or more likely starting 
> at different times. 
> 
> For processors that run at (say) 2GHz, several million (say 10 million) 
> represents a difference of 10e6/2e9 = 0.005 seconds between when the 
> processors were sufficiently powered up to start counting cycles.
> 
> Rob.

If it were so, than why can't the delta of time between the processors 
be set to exact zero?
I assume, that it is known how many cycles adjusting the value will 
take, so it could be done exactly ... hmmm ...

Claudio Grondi