Include suspend time on minipal ticks for Unix-like systems by marzent · Pull Request #119443 · dotnet/runtime

marzent · 2025-09-07T17:53:23Z

On macOS, this uses CLOCK_MONOTONIC_RAW (and CLOCK_MONOTONIC_RAW_APPROX for low-res ticks as a mini-optimization here) and on Linux uses CLOCK_BOOTTIME when available now.

Emscripten only fully implements CLOCK_MONOTONIC on all platforms, so leave it at that.

Of note is that this loses the optimization done in dotnet/coreclr#2293, since there is no CLOCK_BOOTTIME_COARSE; however, as of Linux 5.0, all of CLOCK_BOOTTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_COARSE are handled via a fast path in vDSO on at least x86/arm64 in the low nanosecond range.

On my arm64 machine with kernel 6.15.6, I couldn't even measure a meaningful difference between any of these three at least.

Fixes #77945 and #119437

Uses CLOCK_MONOTONIC_RAW for hires and CLOCK_MONOTONIC_RAW_APPROX for lowres ticks. Fixes dotnet#119437

Copilot

Pull Request Overview

This PR updates the time measurement implementation on Unix-like systems to include suspend time in the clock measurements. The change switches from uptime-based clocks to suspend-inclusive clocks to provide more accurate time tracking across system sleep/wake cycles.

Key changes:

Switch from CLOCK_UPTIME_RAW to CLOCK_MONOTONIC_RAW on macOS systems
Prefer CLOCK_BOOTTIME over CLOCK_MONOTONIC on Linux when available
Remove the CLOCK_MONOTONIC_COARSE optimization in favor of consistent suspend-inclusive timing

src/native/minipal/time.c

Uses CLOCK_BOOTTIME for hires/lowres ticks. Fixes [dotnet#119437](dotnet#119437)

marzent · 2025-09-07T17:59:57Z

@dotnet-policy-service agree

jkotas · 2025-09-07T19:32:50Z

How does this change interact with existing places that deal with timeouts and use the existing timer?

For example,

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/WaitSubsystem.ThreadWaitInfo.Unix.cs

Lines 344 to 357 in ffafc0d

    
           bool monitorWaitResult = _waitMonitor.Wait(timeoutMilliseconds - elapsedMilliseconds); 
        
           // It's possible for the wait to have timed out, but before the monitor could reacquire the lock, a 
        
           // signaler could have acquired it and signaled to satisfy the wait or interrupt the thread. Accept the 
        
           // signal and ignore the wait timeout. 
        
           int waitResult = ProcessSignaledWaitState(); 
        
           if (waitResult != WaitHandle.WaitTimeout) 
        
           { 
        
               return waitResult; 
        
           } 
        
           if (monitorWaitResult) 
        
           { 
        
               elapsedMilliseconds = Environment.TickCount - startTimeMilliseconds;

calls
SystemNative_LowLevelMonitor_TimedWait that is still on CLOCK_MONOTONIC plan and it combines it with TickCount that is on CLOCK_BOOTTIME plan now.

I am changing the area to System.Threading.

cc @jkoritzinsky

marzent · 2025-09-08T09:47:37Z

How does this change interact with existing places that deal with timeouts and use the existing timer?

This is actually a really good question. Since the timeout passed into SystemNative_LowLevelMonitor_TimedWait is relative this doesn't really make a difference, except for if the pthread condition variable does count time in suspend or not...

On macOS this is wall time in my testing (can also be verified in Apples libc source of _pthread_cond_wait that uses gettimeofday), so this PR would be a better fit even, if that ever was a problem.

On Linux this would create a discrepancy there (again not too sure if it is actually meaningful, and could worst case be fixed by using the appropriate clock in pthread_condattr_setclock).

Notably the Windows codepath, which I believe ends up in WaitForSingleObjectEx on first glance, also shows some interesting behavior according to MSDN:

Windows XP, Windows Server 2003, Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2: The dwMilliseconds value does include time spent in low-power states. For example, the timeout does keep counting down while the computer is asleep.
Windows 8 and newer, Windows Server 2012 and newer: The dwMilliseconds value does not include time spent in low-power states. For example, the timeout does not keep counting down while the computer is asleep.

So with this change Linux would probably behave as "badly" as modern Windows, when combining TickCount (with suspend time) + Monitor Wait (without suspend time) here I believe.

This also means that for macOS the current interaction without this PR is the TickCount (without suspend time) + Monitor Wait (with suspend time) scenario.

tannergooding · 2025-09-08T19:06:13Z

It's worth noting that "best practice" when dealing with something like elapsed/delta times is to clamp the times that are "egregious" so that it behaves generally as expected in the face of things like a debugger breakpoint as well.

There's always going to be various quirks over how timing is tracked and whether it considers low power states, clock frequency changes, app suspension, general OS thread/process management, etc.

It would be "nice" if most of the OS generally followed the same behavior with regards to whether something like sleep/hibernation time (as defined by ACPI) was tracked; but it won't "fix" the broader issue here.

marzent · 2025-09-17T11:00:27Z

Is there anything else that needs to be done in this PR besides the two commits?

This is my first time contributing, and I’m happy to address any issues if anything needs changing.

I don’t believe it’s necessary to modify CLOCK_MONOTONIC in other parts of the code for this change. Also, it seems that special care is taken for the macOS codepaths to (reasonably) ensure that waits exclude suspend time, similar to how CLOCK_MONOTONIC works on Linux, and similar to modern Windows waits.

jkotas · 2025-09-17T16:50:46Z

This change is fixing Environment.TickCount and friends on non-Windows to match Windows behavior and what's written in the documentation. However, doing that is going to introduce bugs in other parts of the core libraries. The bugs that this change is introducing may be worse than the bugs that it is fixing. It is not clear what the net impact is to me.

Note that there are Windows specific places in the code like

runtime/src/libraries/System.Private.CoreLib/src/System/Threading/TimerQueue.Windows.cs

Lines 28 to 33 in 55d09c7

    
           // Based on its documentation the QueryUnbiasedInterruptTime() function validates 
        
           // the argument is non-null. In this case we are always supplying an argument, 
        
           // so will skip return value validation. 
        
           bool success = Interop.Kernel32.QueryUnbiasedInterruptTime(out ulong time100ns); 
        
           Debug.Assert(success); 
        
           return (long)(time100ns / 10_000); // convert from 100ns to milliseconds

that compensate for the discrepancy between Environment.TickCount and other APIs. We may need to replicate this on non-Windows. We may even want to introduce new public APIs that expose times that align with timers used for timeouts.

xtqqczze · 2025-10-27T23:38:45Z

@jkotas Does this PR have a reasonable path toward acceptance?

NinoFloris · 2025-10-28T00:01:58Z

I would certainly appreciate this to be consistent across platforms, and ideally such that it uses the cheapest (perf-wise) mechanisms to retrieve TickCount64. macOS isn't very cheap today for example, and it shows up in profiles there. It's not that I intrinsically care about macOS perf that much. However as it is my main dev platform I have to mentally ignore these kind of hotspots that aren't as pronounced on linux.

jkotas · 2025-10-28T00:37:11Z

@jkotas Does this PR have a reasonable path toward acceptance?

It needs to address this "However, doing that is going to introduce bugs in other parts of the core libraries. The bugs that this change is introducing may be worse than the bugs that it is fixing. It is not clear what the net impact is to me."

marzent · 2025-10-28T11:25:50Z

I am sorry for the late update on this, I haven't had much time to work on it lately...

If my understanding is correct, we just need to provide a Linux/macOS equivalent for QueryUnbiasedInterruptTime, and use it in all places where QueryUnbiasedInterruptTime is used currently in place of TickCount for the Windows codepath.

I will try to implement this, but it looks to be a larger change.

agocke · 2025-11-04T22:12:29Z

@marzent No problem -- in that case, I'm going to move this to draft

dotnet-policy-service · 2025-12-04T22:48:56Z

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

Include suspend time on macOS for minipal ticks.

f10af96

Uses CLOCK_MONOTONIC_RAW for hires and CLOCK_MONOTONIC_RAW_APPROX for lowres ticks. Fixes dotnet#119437

Copilot AI review requested due to automatic review settings September 7, 2025 17:53

github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 7, 2025

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Sep 7, 2025

Copilot AI reviewed Sep 7, 2025

View reviewed changes

src/native/minipal/time.c Outdated Show resolved Hide resolved

src/native/minipal/time.c Outdated Show resolved Hide resolved

src/native/minipal/time.c Outdated Show resolved Hide resolved

src/native/minipal/time.c Outdated Show resolved Hide resolved

Include suspend time on Linux for minipal ticks.

390cd2b

Uses CLOCK_BOOTTIME for hires/lowres ticks. Fixes [dotnet#119437](dotnet#119437)

marzent force-pushed the issue-119437 branch from 080aa9b to 390cd2b Compare September 7, 2025 17:58

marzent mentioned this pull request Sep 7, 2025

TickCount on macOS/Linux does not include suspend time #119437

Closed

marzent changed the title ~~Include suspend time on minimal on Unix-like systems~~ Include suspend time on minipal ticks for Unix-like systems Sep 7, 2025

jkotas added area-System.Runtime and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Sep 7, 2025

jkotas added area-System.Threading and removed area-System.Runtime labels Sep 7, 2025

lewing mentioned this pull request Sep 11, 2025

[Perf] Linux/x64: 11 Improvements on 9/8/2025 6:18:48 AM +00:00 dotnet/perf-autofiling-issues#62322

Closed

xtqqczze mentioned this pull request Oct 9, 2025

Use Environment.TickCount64 in GetUptimeCommand PowerShell/PowerShell#26151

Closed

agocke marked this pull request as draft November 4, 2025 22:12

dotnet-policy-service bot closed this Dec 4, 2025

jkotas mentioned this pull request Dec 22, 2025

Use QueryUnbiasedInterruptTime instead of GetTickCount64 to allow more responsive Windows apps when they opt-in #122706

Merged

github-actions bot locked and limited conversation to collaborators Jan 4, 2026

Conversation

marzent commented Sep 7, 2025 • edited by jkotas Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marzent commented Sep 7, 2025

Uh oh!

jkotas commented Sep 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marzent commented Sep 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tannergooding commented Sep 8, 2025

Uh oh!

marzent commented Sep 17, 2025

Uh oh!

jkotas commented Sep 17, 2025

Uh oh!

xtqqczze commented Oct 27, 2025

Uh oh!

NinoFloris commented Oct 28, 2025

Uh oh!

jkotas commented Oct 28, 2025

Uh oh!

marzent commented Oct 28, 2025

Uh oh!

agocke commented Nov 4, 2025

Uh oh!

dotnet-policy-service bot commented Dec 4, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

marzent commented Sep 7, 2025 •

edited by jkotas

Loading

jkotas commented Sep 7, 2025 •

edited

Loading

marzent commented Sep 8, 2025 •

edited

Loading