High-res timers for Windows with IOCP support

[reinar]

This PR adds high-resolution timer support for Windows (doc, available from Windows 10, version 1803) and if such support is enabled - associates it with iocp port to get rid of separate timer thread.

Feature is gated behind ASIO_ENABLE_IOCP_HIRES_TIMERS define, so default behavior won't be changed from previous versions of asio.

Both on and off states for the feature were tested on Windows 11 26100.7171 with MSVC 19.50.35718 and clang-cl 21.1.6 (default unit test setup, just overridden with boost 1.89.0. Unit tests are passing).

Fixes #1404, #1328

[NiceAndPeter]

Thank you for your work. Do you have some benchmarks on what timer resolution is achievable with your patch ?

[reinar]

@NiceAndPeter it's a good and interesting question.
My PR is essentially 2 changes:

• Add CREATE_WAITABLE_TIMER_HIGH_RESOLUTION support
• Associate the high-resolution timer with existing I/O competition port to unify timer handling.

Raw high-resolution timer can fire as soon as 10's of microseconds after setting it, but it's 2nd part of my PR is where we start gaining latency - it costs up to 500us to dequeue the event from iocp (NtRemoveIoCompletion is blocking). It's relatively predictable cost and with a bit of trickery on the handler side you can get your timer loop to run at around 2000Hz in a good enough manner for general-purpose OS. Numbers are for my machine (i9-12900K), your results may vary.

While it's sad that we don't have a possibility to reduce/eliminate this latency, I see it as acceptable tradeoff to uncontrollable timer thread that can miss really badly due to scheduling - it's not easy to raise its priority. So even if I remove/gate the 2nd part of my PR behind a separate flag it won't bring much benefits while severely reducing determinism due to scheduling.

Theoretically, it might be interesting to try to dequeue more than 1 event at a time to improve the throughput which will result in better times for some scenarios, but I don't think that's worth it

[NiceAndPeter]

Thanks for your reply. At work we have to simulate an embedded measuring system. Something below 1ms would be acceptable. Right now, we use a loop that compares timepoints to get reasonable timing on windows. I plan to tests your timers next year.

[reinar]

I don't think this PR would solve your problem in this case, for simulating embedded/realtime systems Windows scheduler is simply not enough. Problem is actually determinism - the the fastest or even average/median samples are not representative, since Windows scheduling is best-effort events could be delayed for whatever amount of time, it's very realistic and possible to miss several or 10's of timer ticks - you never know.

If Windows/Intel (AMD is a separate topic, Intel has bunch of extensions for realtime workloads - cache partitioning, tcc, rdt) is a must, then generally you'd better off with building mixed criticality system with Project ACRN. Or if crazy amount of jitter is acceptable then you can use asio + this patch on Windows, but it's hard to imagine embedded system where general-purpose OS lackluster timers are a good fit.

[NiceAndPeter]

Thanks again. We use the simulation more as a quick test and to run unit tests both on the developer pc as in the CI pipeline. The 16ms scheduling is too bad for throughput tests and a factor of 16x slowdown is not acceptable. I know we cannot achieve determinism on most PC platforms and windows in particular. I will give your patch a try anyway, because our current solution is quite ugly with busy waiting in an asio handler :-< Am So., 21. Dez. 2025 um 00:38 Uhr schrieb Reinar ***@***.***

…

: *reinar* left a comment (chriskohlhoff/asio#1685) <#1685 (comment)> I don't think this PR would solve your problem in this case, for simulating embedded/realtime systems Windows scheduler is simply not enough. Problem is actually determinism - the the fastest or even average/median samples are not representative, since Windows scheduling is best-effort events could be delayed for whatever amount of time, it's very realistic and possible to miss several or 10's of timer ticks - you never know. If Windows/Intel (AMD is a separate topic, Intel has bunch of extensions for realtime workloads - cache partitioning, tcc, rdt) is a must, then generally you'd better off with building mixed criticality system with Project ACRN. Or if crazy amount of jitter is acceptable then you can use asio + this patch on Windows, but it's hard to imagine embedded system where general-purpose OS lackluster timers are a good fit. — Reply to this email directly, view it on GitHub <#1685 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BXK37JIVOV3POKPTAAZZEGD4CXMXRAVCNFSM6AAAAACM6DF2WGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZYGIYDSNBRGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>