Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

QueryPerformanceCounter Win32 timer slower than normal

4: Adsense

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   Members   


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.

#22 L. Spiro   Members   


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

#23 / slalrbalr   Banned   


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.