Fix flaky CounterSampleCalculator_ElapsedTime test

[danmoseley]

I got this on an unrelated PR.

Note

This PR was authored with assistance from Copilot CLI.

The CounterSampleCalculator_ElapsedTime test occasionally fails in CI (0.01% rate) because it compares elapsed time measured by two different clock sources: QPC (via the perf counter infrastructure) and DateTime.Now (over system clock, updated by periodic interrupt). Under CI load, the gap between Stopwatch.GetTimestamp() and DateTime.Now on consecutive lines can exceed the 0.3s tolerance.

Assert.True() Failure
Expected: True
Actual:   False
   at System.Diagnostics.Tests.CounterSampleCalculatorTests.CounterSampleCalculator_ElapsedTime() in /_/src/libraries/System.Diagnostics.PerformanceCounter/tests/CounterSampleCalculatorTests.cs:line 29

Fix by using Stopwatch for both measurements so they share the same clock source (QPC). Can't use .GetElapsedTime() as that wasn't in .NET Framework.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/area-system-diagnostics-tracing
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Addresses flakiness in CounterSampleCalculator_ElapsedTime by ensuring elapsed-time comparisons use a consistent clock source.

Changes:

• Replaced DateTime.Now-based elapsed measurement with a Stopwatch-based calculation.
• Removed unused using directives.

Show a summary per file

File	Description
src/libraries/System.Diagnostics.PerformanceCounter/tests/CounterSampleCalculatorTests.cs	Updates the elapsed-time test to compute expected duration using Stopwatch (QPC) and cleans up unused usings.

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 2

[adamsitnik]

LGTM, thank you for fixing another flaky test @danmoseley !

[jkotas]

the gap between Stopwatch.GetTimestamp() and DateTime.Now on consecutive lines can exceed the 0.3s tolerance.

This does not make sense. Both of these have sub-millisecond granularity.

I agree that tests with small hardcoded time spans are prone to failing intermittently on overloaded machines due to thread scheduling happening at the right moment. Changing the time source won't fix these failures. The fix for these failures should be to either increase the hardcoded time span or to add a retry loop.

[danmoseley]

I had read that the system clock was updated on a 15ms interrupt, while the fine grained timer was not?

I'll add a loop.

[Copilot]

Copilot's findings

• Files reviewed: 1/1 changed files
• Comments generated: 2

[jkotas]

I had read that the system clock was updated on a 15ms interrupt,

It might in some cases, but that's still 20x less than 0.3 seconds that we allow currently.

[danmoseley]

Yeah I looped against the Windows API's on a machine that was artificially loaded (quite different to CI hardware no doubt)

GetSystemTimePreciseAsFileTime, QueryPerformanceCounter, DateTime.UtcNow.Ticks diverged by up to 0.1-0.2ms only.

So I guess the cause was scheduling causing the perf counter read and the our time read to be separated by 30ms.