Strange behavior of TimerDiff

[yupepa]

On some PC's (Intel Core2 Duo, E8400 3GHz) i have got strange results with timers.

$begin = TimerInit() 
Sleep(5000) 
MsgBox(0, "Timer", "Duration = "& TimerDiff($begin))

The result always differs, between 200 and 500. Same behavior with timers UDF.

It seems that the problem is in the functions QueryPerformaceCounter and QueryPerformanceFrequency. There exists a blog concerning the problems with it: ​http://www.virtualdub.org/blog/pivot/entry.php?id=106

My solution:

$begin = f_timeGetTime() 
Sleep(1234) 
$end = f_timeGetTime() 
$diff = $end - $begin 
MsgBox(0, "Timer1", "Diff = "&$diff) 

Func f_timeGetTime() 
Local $aResult = DllCall("winmm.dll", "long", "timeGetTime") 
If @error Then Return SetError(@error, @extended, -1) 
Return $aResult[0] 
EndFunc ;==>f_timeGetTime

[yupepa]

The exists a discussion in the forum unter the entry "Strange behavior of TimerDiff".

[Valik]

What do you want us to do about it? Change the behavior because a limited number of systems have issue with the function? The function works fine for most people because most people have a system that does sensible things with QueryPerformanceCounter() and QueryPerformanceFrequency().

In addition, since you didn't bother to actually provide any output from your scripts, how do I know it's not just the well known sleep inaccuracy + AutoIt overhead? I don't.

I'm closing this as won't fix. As I said, most people's system give consistent and sensible results so changing the behavior of the function to cater to the minority makes little sense.

[anonymous]

Replying to Valik:
For me its fine since my probem is solved. I have been advised to make a bug report by trancexx.

In addition I didn't want to overload the ticket with additional screen pictures which are allready in the forum thread, anyhow as you could see in the listing, with a sleep of 5000 there is a result between 200 and 500 which could not be the well known sleep accuracy since it is much smaller.

What do you want us to do about it? Change the behavior because a limited number of systems have issue with the function? The function works fine for most people because most people have a system that does sensible things with QueryPerformanceCounter() and QueryPerformanceFrequency().

In addition, since you didn't bother to actually provide any output from your scripts, how do I know it's not just the well known sleep inaccuracy + AutoIt overhead? I don't.

I'm closing this as won't fix. As I said, most people's system give consistent and sensible results so changing the behavior of the function to cater to the minority makes little sense.

[Valik]

Why do people think they have to take screenshots of error messages?

1. A message box's text can be copied by Ctrl+c.
2. Output to the console, display console output. Duh.

As for the sleep inaccuracy, notice I also added "AutoIt overhead". Finally, you didn't provide a link to the forum thread and I'm certainly not going to spend my time searching for it. If trancexx wants to fix this in a way that doesn't change the behavior she can but I think that it is pointless waste of time. The function works for most people. For the rest most people won't even care about being off for a few hundred milliseconds. Of that super small subset that do care they can use a different method as you have done.

[trancexx]

My intention wasn't to fix anything. The issue can't be fixed. This is not about small error in calculation or maybe TimerDiff() inacuracy of some sort. This is about complete failure. The user has hardware (specific type of processor) for which our function doesn't work correctly. It's not about software.
Anyway, situation about the bug is very specific. Our function description should include disclamer. Won't fix would have been my resolution too.

The main purpose of this ticket is future referencing.

[yupepa]

Replying to trancexx:
Just for my information, which functions are behind TimerInit and TimerDiff()?

[Valik]

Why would I talk about QueryPerformanceCounter() and QueryPerformanceFrequency() in comment 2 if we were using something else?

[anonymous]

So maybe it makes sense to add my function to the timers udf to help others which run into similar problem?

[Valik]

Replying to anonymous:

So maybe it makes sense to add my function to the timers udf to help others which run into similar problem?

That is not and would never be a good reason to add a function to the language. Things should be useful for the majority, not the minority.

It's all a moot point, anyway. The function _Date_Time_GetTickCount() already exists and does the same thing although it uses GetTickCount() instead of timeGetTime(). Since you aren't using timeBeginPeriod() and timeEndPeriod() your resolution isn't really any more or less accurate than GetTickCount() unless some other program has requested a high resolution. Further, since timeBeginPeriod() changes the entire system it should be left up to the application (read: user) to call it, not hide it away behind some API.

[yupepa]

Ok, thanks for the infos.

[trancexx]

Addressed by revision [7170]

[AdmiralAlkex]

This ticket is referenced in revision: [7182]

Arggg. No it isn't. Wrong number. Ignore this.