[Tcl-bugs] [ tcl-Bugs-3002022 ] clock microseconds broken on Windows

[SourceForge.net <no...@so...>]

Bugs item #3002022, was opened at 2010-05-15 03:25
Message generated for change (Comment added) made by kennykb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3002022&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 06. Time Measurement
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Helmut Giese (hgiese)
Assigned to: Kevin B KENNY (kennykb)
Summary: clock microseconds broken on Windows

Initial Comment:
Hello out there,
I think that 'clock microseconds' is broken under Windows.

There was recently a thread on clt
    clock microseconds with resolution in milliseconds
which stated that you only ever get a millisecond resolution - that is you get values like 1273904070156000 or 1273904072243000 but never any value other than '000' in the 3 low order digits.

I could verify this on my Intel Core 2 Duo machine - and it really surprised me, because in the past I had been using 'clock microseconds' to get detailed timing information - just not on this machine. Why did Tcl lose the useful capability?

I had a look at the sources and I am near to certain to have found the culprit: NativeGetTime (tclWinTime.c) is broken.

Analysis:
On its first invocation NativeGetTime checks via QueryPerformanceFrequency whether a performance counter exists - so far, so good.
However, if its frequency is > 15 MHz (and on my machine it is 2.5 GHz) it enters a complex test which can result in declaring the performance counter as 'not available', and this test is "out of date":
a) In its first part it only accepts 'GenuineIntel' - very bad for AMD chips.
b) In its second part it seems to not be 'up to date': Apparently Intel has defined different values for newer cores which this test does not check - hence the failure on newer machines.

Possible solutions:
a) Get rid of this second test.
What is the scenario where it makes sense to declare the performance counter to not be available, even if Windows has just told us the opposite?
b) If we need to keep it, it needs to be brought up to date:
- Accept other CPUs than Intel only, and
- for each core of the different vendors get the tests right

I attach a C file which which is self-contained and which shows the relevant information (frequency and register values) - this may make it easier to get or verify the details for different cores.
If there is a reason to go route (b) I could put this file on the wiki and we could ask people on clt to support this issue by running it on all possible cores (that's the reason it is self-contained and does not need Tcl's sources to compile - hopefully makes it a bit easier).

Still, the easiest way would be to just drop the second test.
Best regards
Helmut Giese


----------------------------------------------------------------------

>Comment By: Kevin B KENNY (kennykb)
Date: 2010-05-15 17:40

Message:
The scenario that causes the problem is that QueryPerformanceCounter
returns different values on different cores. And that scenario is still
with us. Microsoft warns that "bugs in the HAL" may cause such behaviour
and suggests that any code that uses QueryPerformanceCounter set a thread
affinitiy mask to run single-core. What they don't say is that the "bug" is
universal - I have yet to find multichip systems where
QueryPerformanceCounter returns consistent results, and even some
single-chip multicore systems seem to get out of sync.

I'm really at a loss what to do with this one. We seem to be faced with a
choice between restricting a Tcl process to a single core in order to get
robust timing, or else giving up on submillisecond resolution. The
manufacturers of Windows machines simply do not care about this problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3002022&group_id=10894