I have a 3rd party application that doesn't work properly if it detects a timeout condition. For some reason, my computer clock seems to lose about 90 seconds each day, so that when Windows does its daily NTP synchronization, I get Event ID 50: Time Service detected a time difference of greater than 5000 milliseconds for 900 seconds. When this happens the clock is changed by over a minute, which is sometimes enough to break my application (a change of over 60 seconds at certain particular moments in the periodic execution cycle will trigger a timeout).
I found that there is a registry setting in HKLM\SYSYTM\CurrentControlSet\Services\W32Time\TimeProvider\NtpClient called SpecialPollInterval that can force the time to sync more often which I hope will fix my problem. (Still in the process of testing). However I was wondering if there is any way to make so time synchronization happens more gradually. For example, if the clock notices it is 90 seconds behind, can it just gain 1 second every minute so that in 90 minutes its back in sync, or better yet, can it realize (after resyncing) that its about 0.1% slow and therefore every hardware second, 1.01 real seconds are transpiring so that it never needs to have time jumps again?
Update: I thought the Event ID 50 was because the clock was off by more than 5 seconds, but I am starting to believe that this isn't the case and perhaps the 5 seconds refers to how long it is taking to make a network trip or maybe that the clock of the remote time server (which in this case is a corporate computer somewhere) has changed.
Update #2: It looks like the reference for how the windows time service works is given here: https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings
I think the 5000 milliseconds is actually the LargePhaseOffset which is described as:
Specifies that a time offset greater than or equal to this value in 10-7 seconds is considered a spike. A network disruption such as a large amount of traffic might cause a spike. A spike will be ignored unless it persists for a long period of time. The default value on domain members is 50000000. The default value on stand-alone clients and servers is 50000000.
(Note that 50000000 * 10e-7 seconds = 5 seconds = 5000 milliseconds)
The 900 seconds must be the SpikeWatchPeriod which is described as:
Specifies the amount of time that a suspicious offset must persist before it is accepted as correct (in seconds). The default value on domain members is 900. The default value on stand-alone clients and workstations is 900.
