Jump to content

Time Sync plus SystemTimeAdjustment


Recommended Posts

I learned a lot from my earlier post in General Help and Support section. I especially thank @TheXman for his kind help and guidance.

The time-of-day clock in any desktop or a laptop computer does not keep the time very well. Usualy it gains or loses several seconds a day. I wanted my desktop's system time to be as accurate as possible without consuming too much of resources. I came up with this program and I am satisfied with it. I am pretty sure that my desktop's system time is always within 20 milliseconds of NTP server time.

The following is time sync log of my desktop for a typical day. Created by my NTP_TimeSync.au3, this log shows what the program does.

2021/12/19 06:16:53.887 Offset: -0.360 second(s), GGL Latency: 59.505 milliseconds*4
This is the first line which shows that my desktop was turned on at 6:16 in the morning and it's system time was sync'ed to NTP time. The desktop must have picked up the initial system time from its CMOS clock and it was 360 milliseconds ahead of the NTP server time. It took 59.505 milliseconds to fetch NTP time from Google time server. *4 at the end of the line indicates that periodic time adjustment was enabled and my desktop's clock was set to run at the rate of 4/156250 faster than the default time keeper, by using _Date_Time_SetSystemTimeAdjustment() function. This means the system time will gain 23.04*4=92.16 milliseconds every hour. This number(4) was picked up from an ini file, which is created when this program is run for the first time.

2021/12/19 11:55:02.322 Offset: -0.017 second(s), GGL Latency: 55.908 milliseconds*3
This is the seventh line which shows that my desktop's clock was running too fast now and the SystemTimeAdjustment value was reduced by 1 unit. The program must have updated the ini file as well. I found that my desktop needs 3 or 4 units of spike in SystemTimeAdjustment value for a typical day. With 4, the clock runs a little too fast; with 3, it runs a little too slow. If my program is run in 1-hour intervals, it will usually find an optimum SystemTimeAdjustment value in several hours and record it in NTP_TimeSync.ini file. This value is applied at the time of logon and the system time offset will be continuously monitored to see if an adjustment is required of this value.

As can be seen in the log, the program is run every hour. I have a Windows Task where two triggers are defined: one to run upon logon and another to run every hour thereafter at 55 minutes of each hour. The Task was set up to run with highest privileges to allow time reset without security alert.

The periodic time adjustment function is disabled when the time-of-day is reset by the Windows default time sync mechanism. So I turned it off in "Time and language - Date and time - Set time automatically" of Windows 10 Settings menu. This function reverts to disabled status when the device is turned off.

I chose Google as my primary time server after comparing several alternatives. Though pool.ntp.org has usually far shorter response times, Google was most consistent in terms of standard deviation of response times.

2021/12/18 22:57:24 Shutdown
2021/12/19 06:16:53.887 Offset: -0.360 second(s), GGL Latency: 59.505 milliseconds*4
2021/12/19 06:55:01.794 Offset: -0.010 second(s), GGL Latency: 56.038 milliseconds
2021/12/19 07:55:01.829 Offset: -0.012 second(s), GGL Latency: 58.372 milliseconds
2021/12/19 08:55:01.783 Offset: -0.014 second(s), GGL Latency: 57.055 milliseconds
2021/12/19 09:55:01.825 Offset: -0.011 second(s), GGL Latency: 62.304 milliseconds
2021/12/19 10:55:02.331 Offset: -0.014 second(s), GGL Latency: 60.053 milliseconds
2021/12/19 11:55:02.322 Offset: -0.017 second(s), GGL Latency: 55.908 milliseconds*3
2021/12/19 12:55:02.337 Offset: +0.010 second(s), GGL Latency: 57.104 milliseconds
2021/12/19 13:55:02.352 Offset: +0.008 second(s), GGL Latency: 55.385 milliseconds
2021/12/19 14:55:02.342 Offset: +0.011 second(s), GGL Latency: 58.324 milliseconds
2021/12/19 15:55:02.351 Offset: +0.010 second(s), GGL Latency: 59.801 milliseconds
2021/12/19 16:55:02.344 Offset: +0.009 second(s), GGL Latency: 57.410 milliseconds
2021/12/19 17:55:02.352 Offset: +0.009 second(s), GGL Latency: 57.528 milliseconds
2021/12/19 18:55:02.393 Offset: +0.011 second(s), GGL Latency: 58.598 milliseconds
2021/12/19 19:55:02.408 Offset: +0.010 second(s), GGL Latency: 58.423 milliseconds
2021/12/19 20:55:02.345 Offset: +0.010 second(s), GGL Latency: 57.704 milliseconds
2021/12/19 21:55:02.368 Offset: +0.009 second(s), GGL Latency: 55.841 milliseconds
2021/12/19 22:55:02.375 Offset: +0.009 second(s), GGL Latency: 57.590 milliseconds
2021/12/19 23:34:34 Shutdown

Edited Jan 13, 2022: I found that the system time offsets vs server time, when calculated several times in short successions,  can vary up to 5 msilliseconds depending on the internet latency. So i changed my code to calculate system time offsets 5 times in 200 ms intervals and take the median value as the true offset. I also took care of Daylight Saving Time issue in log file by logging current time instead of system time adjusted by time zone offset. The new source code is attached as NTP_TmeSync_2.au3.

 

NTP_TimeSync.au3

 

 

NTP_TimeSync_2.au3

Edited by CYCho
Link to post
Share on other sites
Link to post
Share on other sites
8 hours ago, ptrex said:

Not sure what the advance is compared to using the standard Windows NTP function ?

This code not only syncs the time but also makes the device a better clock by adjusting the rate of system time movement. From my log above, you see that the hourly sync offset is 10 to 15 milliseconds. If I did not use _Date_Time_SetSystemTimeAdjustment() function, the hourly offset would be somewhere between 70 and 90 milliseconds. If I were to obtain such accuracy of the clock with Windows regular time sync function,  I would have to poll the sync function far more frequently. This code statiscally calculates the optimum amount of $iAdjustment parameter on its own.

Edited by CYCho
Link to post
Share on other sites

I found that the system time offsets vs server time, when calculated several times in short successions,  can vary up to 5 msilliseconds depending on the internet latency. So i changed my code to calculate system time offsets 5 times in 200 ms intervals and take the median value as the true offset. I also took care of Daylight Saving Time issue in log file by logging current time instead of system time adjusted by time zone offset. The new source code is attached as NTP_TmeSync_2.au3.

Edited by CYCho
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...