System.Threading.Timer vs System.Threading.Thread.Sleep resolution - .NET Timer not using system clock resolution

Question

Questions: Why is the System.Threading.Timer keeping the 15ms resolution despite the OS clock resolution is much more precise? What is the reco

Answer 1

Why is the System.Threading.Timer keeping the 15ms resolution despite the OS clock resolution is much more precise?

Obviously due to implementation. System.Threading.Timer (and therefore Task.Delay) uses .NET runtime timer queue, that not respects system timer resolution. Furthermore, I ran tests (.net 4.x) windows (7, 10; server 2012, 2016) and found, that WaitHandle.WaitOne() and Monitor.Wait() doesn't respect system timer resolution on WinForms GUI thread too (it's for answer above to use WaitHandle). So, only Thread.Sleep respect it on GUI thread.

What is the recommendable way to achieve 1ms timing events resolution without busy CPU waiting?

One way pointed out by Jim Mischel. But, it have drawbacks like:
Callback executing on windows thread pool thread.
Time interval is relative to the current time.
Time interval is integer ms, so theoretically max precision is 1 ms.
By many reports, 1.5-2 ms precision is practically maximum that you can achieve and only with timeBeginPeriod(1) call.

Another approach is: NtSetTimerResolution and Waitable Timer Objects. You may obtain 0.5 ms resolution (depends on hardware and windows version).
For c# example (It's not the example of your timer class, but example of using this functions in c#), you can check this article.

You also can try Nick's suggestion but need to keep in mind problems with GUI thread.