Sleep not even close to millisecond granularity?

[jbuckmccready]

I think I am maybe missing something obvious. The docs suggest sleep has millisecond granularity (docs here), but here is a very simple program and output (running Windows 10):

#[tokio::main]
async fn main() {
    let now = tokio::time::Instant::now();
    for _ in 0..5 {
        tokio::time::sleep(Duration::from_millis(10)).await;
        println!("{:?}", now.elapsed());
    }
}

Example output from running above code:

24.0514ms
46.9322ms
63.028ms
78.5937ms
93.6151ms

The elapsed times seems wildly wrong - I would expect numbers to be closer to 10, 20, 30, 40, 50. I read "millisecond granularity" to suggest plus or minus 1ms but I am seeing 24ms when I expect 10ms. Also the sleep time is always much greater than 10ms, so it's not just an initial startup/jitter. Is this the expected behavior?

Example output when increasing duration to Duration::from_millis(500):

507.0277ms
1.0235844s
1.5252278s
2.0356587s
2.5392296s

[sfackler]

Windows's sleep granularity is something like ~16 milliseconds IIRC.

[jbuckmccready]

I kind of assumed it was something like that, I'll make a pull request to update the docs to mention it's platform specific/defined and clarify "millisecond granularity" as meaning on the order of milliseconds not down to the millisecond - does that make sense?

[Darksonn]

PRs to improve documentation is always welcome. The millisecond granularity thing comes from the data structure we store the timers in, which keeps the timers around in buckets with the smallest bucket being one millisecond large.

[jbuckmccready]

@Darksonn Ah thanks for clarifying. So the granularity will not be less than 1ms and is not guaranteed to be 1ms due to the platform specific implementation.

[Darksonn]

Pretty much, yeah. There's a previous discussion somewhere in the issue tracker that explains how to configure windows to use a better granularity, which would be good to do in such a documentation PR.