Jump to content

  • Log In with Google      Sign In   
  • Create Account


QueryPerformanceCounter Win32 timer slower than normal


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
22 replies to this topic

#21 samoth   Crossbones+   -  Reputation: 4467

Like
1Likes
Like

Posted 13 November 2013 - 03:53 PM


That doesn't help much, for two reasons:

1) Most games already use the highest process&thread prioritiy available

2) The thread becomes active between intervals of the system timer - you can only hope that it becomes active sooner than later.

 

I still say that the waitable timers are just software timers backed by the system timer

 

No, no, and no.

 

1) Only games made by incompetent programmers use the highest process and thread priorities available. Microsoft explicitly discourages from doing so, as it will seriously interfere with system operability.

2) A thread with a boosted priority will in any case be scheduled before any other thread with the same priority (without boost) is scheduled, and it will in any case prevent such a thread from entering its second quantum. On Win8 onwards, it will interrupt a thread in the middle of a quantum.

3) While that is partly true  -- historically --, it is not true for Windows 7 any more, and even less so for Windows 8, which like Linux 3.10 uses a "tickless" kernel ("mostly tickless" is a more accurate naming). A waitable timer schedules a hardware timer, which fires an interrupt when the time is up. It then makes the thread ready and boosts the thread priority, and reschedules. Sleep simply sets the thread to ready when the scheduler next runs, which still happens periodically in a "tickless" kernel (but a lot less often).


Edited by samoth, 13 November 2013 - 03:55 PM.


Sponsor:

#22 L. Spiro   Crossbones+   -  Reputation: 11949

Like
0Likes
Like

Posted 13 November 2013 - 11:33 PM


The system timer has nothing to do with the mouse, or any other bus-connected device. Devices have their own interrupt that signal the CPU when a hardware event happens

Now you’re getting it!

Ever heard of a hardware timer?  When it expires it causes an interrupt and signal, just like a mouse!

 

 


So, WaitMessage will return when either the timeout expires (as timed by the system-timer)

No.  A message sent is always a signal, and signals are always virtually immediate (measured in microseconds, not milliseconds).

In a standard-issue timer, the delay between its trigger time and the Windows message to handle it (WM_TIMER) is off by a large amount simply because the timer itself used a low-resolution clock for its trigger, not because the signal (message) was delayed by a low-resolution clock.

 

If you set a thread to wait for a signal and then you do a task and then send the signal, that thread will get the signal almost immediately, and all Windows messages are based on the signalling scheme.

 

Hardware timers cause an interrupt that causes a signal that cause an almost immediate response.

Since most systems only have one hardware timer, the operating system uses it to signal the next-in-line timer (taking advantage of the hardware interrupt), then reset the hardware timer to the amount of time left on the next-to-fire timer etc., allowing any number of timers to trigger via hardware interrupt, regardless of the system timer.

This can introduce a slight amount of drift as shown in Hodgman’s experiments; his fired in 0.1 milliseconds worth of drift, but in fact that is just the accumulated error as the operating system readjusts the hardware timer for multiple other timers before finally getting to his.  If his is the only timer on the scheduler, it would likely have had a drift of only about 10-20 microseconds.

 

 

And then there are of course regular timers which are indeed based off the system clock.  These exist as a power-saving way to implement timing when drift is not such a large issue, because the more timers you put on the hardware timer the more drift you get, and this it is generally assumed that the hardware timer should have as little drift as possible.

 

Hence the only way to use the hardware timer is via SetWaitabeTimer().

 

 


so why would they make only the waitable timers high-performance, then?

Read above.

 

 


Everyone (mostly game developers) would just start using them

Most people don’t even know about SetWaitableTimer().

 

 

L. Spiro


It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#23 tonemgub   Members   -  Reputation: 605

Like
0Likes
Like

Posted 14 November 2013 - 04:16 AM

Yeah, I already knew about hardware timers (plural, because there are more of them, not just one). I'm not just "getting it now". :)

The main timer hardware (that the system timer is based on) is the Programmable Interval Timer.

 

There is also the HPET, which is what I think you're referring to as "hardware timer". But for some reason, I always thought it was just a counter, not a programable timer - looking at Wikipedia now, it seems to besaying that the HPET does have programmable capability. :)

 

It would be really nice if MSDN would mention which of the hardware timers are used by the timing/scheduling APIs (and how). Is SetWaitableTimer the only one that uses the HPET, or do you know of any others?

 

Thanks, guys.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS