Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2240 closed Bug (Wont Fix)

Strange behavior of TimerDiff

Reported by: yupepa Owned by:
Milestone: Component: AutoIt
Version: 3.3.8.1 Severity: None
Keywords: Timers Cc:

Description

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

Attachments (0)

Change History (12)

comment:1 Changed 7 years ago by yupepa

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

comment:2 follow-up: Changed 7 years ago by Valik

  • Resolution set to Wont Fix
  • Status changed from new to closed

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.

comment:3 in reply to: ↑ 2 Changed 7 years ago by 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.

comment:4 Changed 7 years ago by 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.

comment:5 follow-up: Changed 7 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 7 years ago by yupepa

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

comment:7 follow-up: Changed 7 years ago by Valik

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

comment:8 in reply to: ↑ 7 ; follow-up: Changed 7 years ago by anonymous

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

comment:9 in reply to: ↑ 8 ; follow-up: Changed 7 years ago by 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.

comment:10 in reply to: ↑ 9 Changed 7 years ago by yupepa

Ok, thanks for the infos.

comment:11 Changed 7 years ago by trancexx

Addressed by revision [7170]

comment:12 Changed 7 years ago by AdmiralAlkex

This ticket is referenced in revision: [7182]

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

Last edited 7 years ago by AdmiralAlkex (previous) (diff)

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.