Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
Open Task Manager to the Performance tab and click on the CPU item on the left, and open a PowerShell command window simultaneously next to it. In the PowerShell window run Get-Uptime, note how the time doesn't match that given by Task Manager (listed at the bottom of the CPU page), it can be off by seconds to minutes or more depending on the uptime of the system. You can see in this StackOverflow answer how various methods of getting uptime have a drift relative to the "real" uptime as given by Task Manager (let's all assume Microsoft got it correct in Task Manager and it's the other methods that are wrong): https://stackoverflow.com/a/34010110/15743074, some methods have no drift while others do.
More info: The C# code behind Get-Uptime uses StopWatch.GetTimeStamp() which uses QueryPerformanceCounter, hidden behind a shim but the fact it uses QPC is also indicated on this Microsoft Learn page about high-resolution timestamps:
The primary API for native code is QueryPerformanceCounter (QPC). For managed code, the System.Diagnostics.Stopwatch class uses QPC as its precise time basis.
Which also states,
QPC is typically the best method to use to time-stamp events and measure small time intervals that occur on the same system or virtual machine.
And the page goes into examples of typical crystal oscillators used in computers and how they will drift relative to the real world by seconds per week. I suspect that when Windows synchronizes its time to a timeserver, any corrections to the time are applied to other time sources which is one of the ones Task Manager uses, so if the clock was fast by a second when it gets updated then some kernel counter has 1 second subtracted which causes Task Manager to show an accurate uptime, but the "number of ticks" does not get adjusted to remove a second--which is all the QPC timers use, an unsynchronized number of ticks.
High-resolution timestamps are accurate to microseconds, but microsecond accuracy doesn't hold over days and weeks, these high-resolution timestamps are intended for short profiling events. Get-Uptime is expected to return long times, sometimes even years if you have a server up forever, therefore it should not be using a high resolution timestamp under the hood because it has known issues with drift against real world clocks when used over days or longer.
Expected behavior
Task Manager "up time" and PowerShell `Get-Uptime` should match each other to a second or better.Actual behavior
Task Manager "up time" and PowerShell `Get-Uptime` are different from each other by seconds or more depending on the uptime of the system. My system has 13 day uptime and the difference is 8 seconds right now, which is admittedly very small at only 0.0007% off after 13 days. The accumulated error will be system dependent and represents an unsynchronized time. Error details
No response
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 7.4.5
PSEdition Core
GitCommitId 7.4.5
OS Microsoft Windows 10.0.19044
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visuals
No response