4 ms·

Try adding timeBeginPeriod(1)/timeEndPeriod(1) around the waitable timer code and you'll see it still wakes up every 16ms.

vardump 6y ago
Pretty interesting. And very alarming. On Win10/1809 timeBeginPeriod does affect SetWaitableTimer resolution, as I'd have expected. On Win10/2004 timeBeginPeriod doesn't seem to affect SetWaitableTimer resolution?! This could certainly break things! SetWaitableTimer documentation lets you understand timeBeginPeriod is expected to affect the resolution. Of course, depending on hardware... but in this case both tests were running on same hardware. "You can change the resolution of your API with a call to the timeBeginPeriod and timeEndPeriod functions. How precise you can change the resolution depends on which hardware clock the particular API uses. For more information, check your hardware documentation." https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setwaitabletimer https://docs.microsoft.com/en-us/windows/win32/api/synchapi/...
- mehrdadn 6y ago
  Might be due to my use of APCs rather than waiting on the object. Not bothered enough to try it myself but I guess you can try WaitForSingleObject on the timer to see if it behaves similarly...
  - vardump 6y ago
    On 2004, I tried timeBeginPeriod(1) and calling Sleep(1) 1000 times. Perplexingly it took a bit under 2 seconds. On 1809 same took about 1.3 seconds. I'm at loss... Windows timers have yet again managed to do really weird, unexpected things. I really hope this mess doesn't affect device drivers, or there could be a world of hurt coming up.
    - mehrdadn 6y ago
      I think it's due to my use of APCs like I said. Try replacing SleepEx(100, TRUE) with WaitForSingleObject(handle, INFINITE). Edit: Never mind. Seems it might not be the APCs. Maybe some callee of Sleep(Ex) is just rounding up the wait interval to a time slice somewhere. Not sure... would need some digging.
      - vardump 6y ago
        I didn't call SleepEx, but just plain old Sleep. I don't see how APCs would have anything to do with this.
        deleted 6y ago
        [deleted]

vardump 6y ago

Pretty interesting. And very alarming. On Win10/1809 timeBeginPeriod does affect SetWaitableTimer resolution, as I'd have expected. On Win10/2004 timeBeginPeriod doesn't seem to affect SetWaitableTimer resolution?! This could certainly break things! SetWaitableTimer documentation lets you understand timeBeginPeriod is expected to affect the resolution. Of course, depending on hardware... but in this case both tests were running on same hardware. "You can change the resolution of your API with a call to the timeBeginPeriod and timeEndPeriod functions. How precise you can change the resolution depends on which hardware clock the particular API uses. For more information, check your hardware documentation." https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-setwaitabletimer https://docs.microsoft.com/en-us/windows/win32/api/synchapi/...

mehrdadn 6y ago
Might be due to my use of APCs rather than waiting on the object. Not bothered enough to try it myself but I guess you can try WaitForSingleObject on the timer to see if it behaves similarly...
- vardump 6y ago
  On 2004, I tried timeBeginPeriod(1) and calling Sleep(1) 1000 times. Perplexingly it took a bit under 2 seconds. On 1809 same took about 1.3 seconds. I'm at loss... Windows timers have yet again managed to do really weird, unexpected things. I really hope this mess doesn't affect device drivers, or there could be a world of hurt coming up.
  - mehrdadn 6y ago
    I think it's due to my use of APCs like I said. Try replacing SleepEx(100, TRUE) with WaitForSingleObject(handle, INFINITE). Edit: Never mind. Seems it might not be the APCs. Maybe some callee of Sleep(Ex) is just rounding up the wait interval to a time slice somewhere. Not sure... would need some digging.
    - vardump 6y ago
      I didn't call SleepEx, but just plain old Sleep. I don't see how APCs would have anything to do with this.
      - deleted 6y ago
        [deleted]