Task.sleep() is inaccurate on Windows

[MarSe32m]

Description
Sleeping a task on Windows for relatively small time intervals, e.g. < 10ms, is inaccruate even when one uses timeBeginPeriod().

Steps to reproduce
The following code

import WinSDK

@main
public struct App {
    public static func main() async throws {
        timeBeginPeriod(1)
        for _ in 0..<100 {
            let sleepTime = try await ContinuousClock().measure {
                try await Task.sleep(for: .milliseconds(1), tolerance: .nanoseconds(0))
            }
            print(sleepTime)
        }
        timeEndPeriod(1)
    }
}

prints

.
.
.
0.0318463 seconds
0.0317875 seconds
0.0313313 seconds
0.0318428 seconds
0.0318439 seconds
0.0312897 seconds
0.0318454 seconds
0.0318362 seconds
0.031353 seconds
0.0318502 seconds
0.0308014 seconds
0.0313329 seconds
0.031854 seconds

Expected behavior
It should print something like 0.001.. seconds.

Using Thread.sleep() from Foundation gives the expected result.

import Foundation
import WinSDK

@main
public struct App {
    public static func main() async throws {
        timeBeginPeriod(1)
        for _ in 0..<100 {
            let sleepTime = ContinuousClock().measure {
                Thread.sleep(forTimeInterval: 0.001)
            }
            print(sleepTime)
        }
        timeEndPeriod(1)
    }
}

.
.
.
0.0018896 seconds
0.0009295 seconds
0.0009292 seconds
0.0019314 seconds
0.0009375 seconds
0.0009266 seconds
0.0019474 seconds
0.0009317 seconds
0.0009317 seconds
0.000954 seconds
0.0009257 seconds
0.0019632 seconds

Environment

• Swift compiler version info:
  Most recently tested with April 1, 2023 nightly snapshot

compnerd.org Swift version 5.9-dev (LLVM b88dc63216c427d, Swift 07efa25c01522c6)
Target: x86_64-unknown-windows-msvc

but this happens also on other versions of the compiler (5.6.*, 5.7.*, 5.8).

[compnerd]

This is very difficult to support. IIRC, the default time quanta on Windows is 10ms (or was it 15ms?). In theory you can do some things that get you a higher resolution (at least in the kernel). However, that will significantly impact battery life. This might require an evolution proposal to explicitly opt-in to a power impacting higher resolution timer beyond the system default.

[grynspan]

It's also worth noting that {Suspending,Continuous}Clock.measure {} has coarser granularity on Windows than on e.g. Darwin.