Have a look at the https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime API which will return a FILETIME with a precision of <1us.
Gary.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
When I use GetLocalTime in server 2019, the time difference is always about 15ms, while in other systems, such as win10 or server2012, the time difference can be accurate to 1ms. What's the reason?
Have a look at the https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime API which will return a FILETIME with a precision of <1us.
Gary.
Hi @Binier
You can check if your server is in time sync but using the following commands, first to get the current time source and then check if your server is in sync.
w32tm /query /configuration
w32tm /stripchart /computer:<ntpserver>
Where the <ntpserver> is the name displayed of the NTP server displayed in the /query command.
The closer the * is to center of the chart the closer the machine is in sync with the time source, as show below, the star is in the middle, the virtual bar is not visible.
C:\WINDOWS\system32>w32tm /stripchart /computer:time.windows.com
Tracking time.windows.com [52.148.114.188:123].
The current time is 11/10/2021 16:47:24.
16:47:24, d:+00.1368399s o:-00.0009302s [ * ]
16:47:26, d:+00.1359580s o:-00.0015288s [ * ]
16:47:28, d:+00.1409762s o:+00.0008702s [ * ]
16:47:30, d:+00.1362405s o:-00.0015157s [ * ]
16:47:33, d:+00.1368453s o:-00.0011690s [ * ]
16:47:35, d:+00.1368819s o:-00.0018538s [ * ]
16:47:37, d:+00.1360475s o:-00.0016876s [ * ]
16:47:39, d:+00.1448457s o:-00.0011661s [ * ]
If you get the following error when running the query command, you will need to start the Windows Time service.
C:\Users\Gary>w32tm /query /configuration
The following error occurred: The service has not been started. (0x80070426)
Gary.
Hi @Binier
I have seen this myself but never looked into it, instead, I changed the API to a counter to get better precision for timings, using QueryPerformanceCounter to over come the 16ms delay with mixed results.
It could be associated to processor scheduling that is used on server based OS as they preference background services rather than foreground programs, and saving processing time. I've found this which might help
https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
Gary.