Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow #9736

stephentoub · 2017-02-23T13:36:38Z

Makes DateTime.UtcNow much more precise, at the expense of being ~2x slower than it was previously.

For example, prior to the change, this code:

var list = new List<long>();
for (int i = 0; i < 20; i++) list.Add(DateTime.UtcNow.Ticks);
foreach (long tick in list) Console.WriteLine(tick);

produced results like:

636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888
636234535450569888

After the change, it produces results like:

636234537051614021
636234537051614039
636234537051614039
636234537051614039
636234537051614039
636234537051614042
636234537051614045
636234537051614045
636234537051614045
636234537051614045
636234537051614045
636234537051614045
636234537051614180
636234537051614180
636234537051614183
636234537051614183
636234537051614183
636234537051614183
636234537051614183
636234537051614183

Fixes https://github.com/dotnet/coreclr/issues/5061
Fixes https://github.com/dotnet/corefx/issues/16405
Closes https://github.com/dotnet/corefx/issues/15739
cc: @vancem, @jkotas

benaadams · 2017-02-23T14:14:00Z

Can it be marked with port to desktop potential? Don't know what the procedure is on it

janvorli · 2017-02-23T13:52:31Z

src/classlibnative/bcltype/system.cpp


-    ::GetSystemTimeAsFileTime((FILETIME*)&timestamp);
+    INT64 timestamp;
+	g_pfnGetSystemTimeAsFileTime((FILETIME*)&timestamp);


A nit - please replace the tab by spaces here.

jkotas · 2017-02-23T14:52:13Z

src/classlibnative/bcltype/system.cpp


 FCIMPL0(INT64, SystemNative::__GetSystemTimeAsFileTime)
 {
    FCALL_CONTRACT;

-    INT64 timestamp;
+	if (!g_fGetSystemTimeAsFileTimeInitialized)


It will save a few cycles to get rid of this volatile check and move the initialization out into separate method. You can do something like this:

extern pfnGetSystemTimeAsFileTime g_pfnGetSystemTimeAsFileTime; void WINAPI InitializeGetSystemTimeAsFileTime(LPFILETIME lpSystemTimeAsFileTime) { HMODULE hKernel32 = WszLoadLibrary(W("kernel32.dll")); if (hKernel32 != NULL) { g_pfnGetSystemTimeAsFileTime = (pfnGetSystemTimeAsFileTime)GetProcAddress(hKernel32, "GetSystemTimePreciseAsFileTime"); } else { g_pfnGetSystemTimeAsFileTime = &::GetSystemTimeAsFileTime; } g_pfnGetSystemTimeAsFileTime(lpSystemTimeAsFileTime); } pfnGetSystemTimeAsFileTime g_pfnGetSystemTimeAsFileTime = InitializeGetSystemTimeAsFileTime(LPFILETIME lpSystemTimeAsFileTime);

The hot path can then be just g_pfnGetSystemTimeAsFileTime((FILETIME*)&timestamp);

Changed to this general approach

jkotas · 2017-02-23T14:56:40Z

src/classlibnative/bcltype/system.cpp

@@ -41,14 +41,35 @@ typedef BOOL (*pfnGetPhoneVersion)(LPOSVERSIONINFO lpVersionInformation);
 pfnGetPhoneVersion g_pfnGetPhoneVersion = NULL;
 #endif

+typedef void(WINAPI *pfnGetSystemTimeAsFileTime)(LPFILETIME lpSystemTimeAsFileTime);
+pfnGetSystemTimeAsFileTime g_pfnGetSystemTimeAsFileTime = NULL;
+Volatile<bool> g_fGetSystemTimeAsFileTimeInitialized = false;

 FCIMPL0(INT64, SystemNative::__GetSystemTimeAsFileTime)


Another thing that should save a few cycles is to change the signature of this method to: void GetSystemTimeAsFileTime(INT64* pTimestamp).

It will make the signature of the underlying windows API match exactly the signature of the FCall. It means that the compiler can compile the FCall to just jmp [g_pfnGetSystemTimeAsFileTime] vs. method with a frame that it is today.

Meaning change the API signature up through to how its called from managed? Makes sense, but I'd like to leave that for a separate change, and leave this one just as the precision change.

Meaning change the API signature up through to how its called from managed?

Right.

this one just as the precision change.

ok

jkotas · 2017-02-23T14:58:13Z

src/classlibnative/bcltype/system.cpp

+		// Try to use GetSystemTimePreciseAsFileTime if it's available (Win8+).
+		// Otherwise fall back to GetSystemTimeAsFileTime.
+		pfnGetSystemTimeAsFileTime func = NULL;
+		HMODULE hKernel32 = WszLoadLibrary(W("kernel32.dll"));


This should be under #ifndef FEATURE_PAL so that we are not trying to load kernel32.dll on Unix.

@janvorli noted this to me offline as well. Fixed.

jkotas · 2017-02-23T14:59:46Z

Can it be marked with port to desktop potential?

Marked https://github.com/dotnet/corefx/issues/15739 as netfx-port-consider

vancem · 2017-02-23T16:59:52Z

LGTM, I would like to document the precision of DateTime.NowUtc to the degree we can. We should update the documentation comment of DateTime.NowUtc to indicate the precision you can expect (which I think is ~1us+ on both Win8+ and Linux but may be as little as 16msec on older OSes.

stephentoub · 2017-02-23T20:31:39Z

@dotnet-bot test OSX x64 Checked Build and Test please
@dotnet-bot test Ubuntu x64 Checked Build and Test please
@dotnet-bot test Windows_NT x64 Debug Build and Test please

stephentoub · 2017-02-23T22:58:44Z

@dotnet-bot test Ubuntu x64 Checked Build and Test please (https://github.com/dotnet/coreclr/issues/9750)

mattjohnsonpint · 2017-02-24T05:48:04Z

+1 Thanks!

mattjohnsonpint · 2017-02-24T15:40:54Z

What about non-windows implementations? clock_gettime(CLOCK_REALTIME) seems appropriate, IMHO.

vancem · 2017-02-24T16:05:07Z

In Issue #5061 @mj1856 collected some useful data about what happens on Linux which I copy here (but the original has links. .

BTW - I did a little rough experimentation. It would seem that we are currently using the gettimeofday() function on Linux (here), which gives roughly the same precision as clock_gettime(CLOCK_REALTIME_COARSE), (and GetSystemTimeAsFileTime on Windows).

It was not completely clear what the granularity is of what we currently do however. We also don't have a clear idea of the cost of the extra precision.

However by arguments I have already made, as long as it is not super-bad, we should make the granularity on Linux at least 1msec, and preferably more like 1usec (probably by using clock_gettime(CLOCK_REALTIME).

stephentoub · 2017-02-24T16:18:10Z

I'll take a look at it later today and submit a PR if needed.

…otnet#9736)

fuerstrainier · 2017-09-26T08:24:22Z

Not only is it slower that way (as stephentoub pointed out), but I also challenge the "more precise" statement.
Our Windows clock gets updated by a reliable UTC clock, which we can use to properly report on (to the authorities) and monitor, but when using GetSystemTimePreciseAsFileTime we start mixing this UTC clock with the local tick rate, which is anything but reliable. So from our perspective GetSystemTimePreciseAsFileTime yields a RANDOM timestamp between two Windows clock updates.

stephentoub · 2017-09-26T12:53:10Z

@fuerstrainier, you're saying you have that problem with GetSystemTimePreciseAsFileTime but not with GetSystemTimeAsFileTime?

fuerstrainier · 2017-09-26T14:07:38Z

@stephentoub yes that is correct. The windows clock (which is read by GetSystemTimeAsFileTime) is updated by a proper external clock and the tick counter (additionally) used by GetSystemTimePreciseAsFileTime is updated by the local machines tick rate, which will tick faster or slower than our reference clock. If it's faster it could even overtake the windows clock updates...

stephentoub · 2017-09-26T14:08:58Z

Thanks, @fuerstrainier.

mattjohnsonpint · 2017-09-29T23:56:19Z

@fuerstrainier - Is there a basis for your claim that it is ticking faster or slower than your reference clock? The considerable documentation on this subject would suggest otherwise.

The GetSystemTimePreciseAsFileTime docs state:

The GetSystemTimePreciseAsFileTime function retrieves the current system date and time with the highest possible level of precision (<1us). The retrieved information is in Coordinated Universal Time (UTC) format.

The Windows Server 2016 Accurate Time docs state:

Programs which require the greatest accuracy with regards to UTC, and not the passage of time, should use the GetSystemTimePreciseAsFileTime API. This assures your application gets System Time, which is conditioned by the Windows Time service.

Perhaps you were thinking of QueryPerformanceCounter such as is used in System.Diagnostics.Stopwatch? The definitive doc on that is Acquiring high-resolution time stamps, which also says to use GetSystemTimePreciseAsFileTime if you want to be bound to reference clocks, which for DateTime.UtcNow we do:

QPC is independent of and isn't synchronized to any external time reference. To retrieve time stamps that can be synchronized to an external time reference, such as, Coordinated Universal Time (UTC) for use in high-resolution time-of-day measurements, use GetSystemTimePreciseAsFileTime.

So, if you feel otherwise, I'd really like to understand why. Thanks.

fuerstrainier · 2017-10-04T11:17:47Z

@mj1856 Thanks for your reply. I have to amend my original statement a bit, since it basically depends on the implementation of the timeservice you are using. If it follows a "stepping" approach (using the SetSystemTime operation), you can get into troubles due to different clock speeds, but if it just "skews" the windows clock (using the SetSystemTimeAdjustment), we have no issue with time continuity. Since I learned today that using the stepping approach is not a good idea anyway, it's not a deal for us anymore. Cheers.

* https://www.nimaara.com/high-resolution-clock-in-net/ * https://blogs.msdn.microsoft.com/ericlippert/2010/04/08/precision-and-accuracy-of-datetime/ * dotnet/coreclr#9736

…otnet/coreclr#9736) Commit migrated from dotnet/coreclr@5ec5c2f

dnfclas added the cla-already-signed label Feb 23, 2017

jkotas approved these changes Feb 23, 2017

View reviewed changes

janvorli reviewed Feb 23, 2017

View reviewed changes

jkotas reviewed Feb 23, 2017

View reviewed changes

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow

141ce2b

stephentoub force-pushed the datetime_precise branch from a851bd8 to 141ce2b Compare February 23, 2017 15:13

karelz added the area-System.Runtime label Feb 23, 2017

jkotas merged commit 5ec5c2f into dotnet:master Feb 24, 2017

stephentoub deleted the datetime_precise branch February 24, 2017 12:25

lmolkova mentioned this pull request Mar 1, 2017

Http request instrumentation with Activity (correlation part2) dotnet/corefx#16393

Merged

stephentoub mentioned this pull request Mar 24, 2017

Add GetSystemTimeAsTicks to System.Native dotnet/corefx#17484

Merged

lmolkova mentioned this pull request Apr 17, 2017

Initialize RequestTelemetry with CorrelationId information microsoft/ApplicationInsights-aspnetcore#385

Closed

jorive pushed a commit to guhuro/coreclr that referenced this pull request May 4, 2017

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow (d…

b32aff4

…otnet#9736)

mattjohnsonpint mentioned this pull request Jul 10, 2017

Integer nanoseconds vs. fractional nanoseconds tc39/proposal-temporal#34

Closed

mikedn mentioned this pull request Aug 20, 2017

Remove empty try's #13493

Merged

karelz modified the milestone: 2.0.0 Aug 28, 2017

lmolkova mentioned this pull request Apr 27, 2018

Confusion with Operation Telemetry Timestamp/BeginTimeInTicks microsoft/ApplicationInsights-dotnet#789

Closed

Suchiman mentioned this pull request Jan 8, 2019

WIP: Move DateTime native code into managed #21848

Closed

dbregman mentioned this pull request Dec 12, 2019

SystemTime::now should use GetSystemTimePreciseAsFileTime where available rust-lang/rust#67266

Closed

cg110 mentioned this pull request Nov 23, 2020

ActivitySource started activities aren't using an accurate utcnow on framework. dotnet/runtime#45111

Closed

MullerWasHere mentioned this pull request Jan 10, 2022

Monitor OccurredEvents ordering fluentassertions/fluentassertions#1728

Closed

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow (d…

daab4ca

…otnet/coreclr#9736) Commit migrated from dotnet/coreclr@5ec5c2f

aputlock mentioned this pull request Mar 5, 2024

Move to Stopwatch.GetTimestamp for measuring duration elastic/apm-agent-dotnet#1654

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow #9736

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow #9736

stephentoub commented Feb 23, 2017 •

edited

benaadams commented Feb 23, 2017

janvorli Feb 23, 2017

stephentoub Feb 23, 2017

jkotas Feb 23, 2017 •

edited

stephentoub Feb 23, 2017

jkotas Feb 23, 2017

stephentoub Feb 23, 2017

jkotas Feb 23, 2017

jkotas Feb 23, 2017

stephentoub Feb 23, 2017

jkotas commented Feb 23, 2017

vancem commented Feb 23, 2017

stephentoub commented Feb 23, 2017

stephentoub commented Feb 23, 2017

mattjohnsonpint commented Feb 24, 2017

mattjohnsonpint commented Feb 24, 2017 •

edited

vancem commented Feb 24, 2017 •

edited

stephentoub commented Feb 24, 2017

fuerstrainier commented Sep 26, 2017 •

edited

stephentoub commented Sep 26, 2017

fuerstrainier commented Sep 26, 2017

stephentoub commented Sep 26, 2017

mattjohnsonpint commented Sep 29, 2017

fuerstrainier commented Oct 4, 2017

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow #9736

Use GetSystemTimePreciseAsFileTime if available in DateTime.UtcNow #9736

Conversation

stephentoub commented Feb 23, 2017 • edited

benaadams commented Feb 23, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas Feb 23, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas commented Feb 23, 2017

vancem commented Feb 23, 2017

stephentoub commented Feb 23, 2017

stephentoub commented Feb 23, 2017

mattjohnsonpint commented Feb 24, 2017

mattjohnsonpint commented Feb 24, 2017 • edited

vancem commented Feb 24, 2017 • edited

stephentoub commented Feb 24, 2017

fuerstrainier commented Sep 26, 2017 • edited

stephentoub commented Sep 26, 2017

fuerstrainier commented Sep 26, 2017

stephentoub commented Sep 26, 2017

mattjohnsonpint commented Sep 29, 2017

fuerstrainier commented Oct 4, 2017

stephentoub commented Feb 23, 2017 •

edited

jkotas Feb 23, 2017 •

edited

mattjohnsonpint commented Feb 24, 2017 •

edited

vancem commented Feb 24, 2017 •

edited

fuerstrainier commented Sep 26, 2017 •

edited