Task.Delay and System.Threading.Timer wrong resolution description

[kirsan31]

System.Threading.Timer https://docs.microsoft.com/en-us/dotnet/api/system.threading.timer?view=net-6.0

The Timer class has the same resolution as the system clock. This means that if the period is less than the resolution of the system clock, the TimerCallback delegate will execute at intervals defined by the resolution of the system clock, which is approximately 15 milliseconds on Windows 7 and Windows 8 systems.

Task.Delay https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.delay?view=net-6.0

This method depends on the system clock. This means that the time delay will approximately equal the resolution of the system clock if the millisecondsDelay argument is less than the resolution of the system clock, which is approximately 15 milliseconds on Windows systems.

This is not true (on windows) both of them doesn't respect system timer resolution below 15 milliseconds. After timeBeginPeriod(1) or NtSetTimerResolution(5000, true, out _) the resolution of System.Threading.Timer and Task.Delay still remains ~15 milliseconds :(

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

System.Threading.Timer https://docs.microsoft.com/en-us/dotnet/api/system.threading.timer?view=net-6.0

The Timer class has the same resolution as the system clock. This means that if the period is less than the resolution of the system clock, the TimerCallback delegate will execute at intervals defined by the resolution of the system clock, which is approximately 15 milliseconds on Windows 7 and Windows 8 systems.

Task.Delay https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.delay?view=net-6.0

This method depends on the system clock. This means that the time delay will approximately equal the resolution of the system clock if the millisecondsDelay argument is less than the resolution of the system clock, which is approximately 15 milliseconds on Windows systems.

This is not true (on windows) both of this doesn't respect system timer resolution below 15 milliseconds. After timeBeginPeriod(1) or NtSetTimerResolution(5000, true, out _) the resolution of System.Threading.Timer and Task.Delay still remains ~15 milliseconds :(

Author:	kirsan31
Assignees:	-
Labels:	Pri3, area-System.Threading.Tasks, :watch: Not Triaged
Milestone:	-

[stephentoub]

cc: @kouvel

[kouvel]

I believe timeBeginPeriod affects the resolution of the clock used for waits and sleeps, but not the resolution of the clock used for GetTickCount or Environment.TickCount. The timer implementation uses GetTickCount to determine if a timer should be triggered, so it wouldn't be affected by the resolution change above.

[kirsan31]

I believe timeBeginPeriod affects the resolution of the clock used for waits and sleeps, but not the resolution of the clock used for GetTickCount or Environment.TickCount. The timer implementation uses GetTickCount to determine if a timer should be triggered, so it wouldn't be affected by the resolution change above.

Yea, so the docs need to be corrected? To clarify that system clock here is not the same as described here. Mention GetTickCount? And / or state explicitly that accuracy cannot be improved by timeBeginPeriod / NtSetTimerResolution.

[kouvel]

Yep I can clarify the docs