# Possible cause of significant clock drifts **URL:** \ **Category:** General Discussion\ **Tags:** ignition80\ **Created:** [September 12, 2025, 11:00pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595 "2025-09-12T23:00:48Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 12, 2025, 11:00pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/1 "2025-09-12T23:00:48Z")
I have a dell server running windows (unfortunately) that is experiencing daily or every other day clock drifts of about -211665ms, and its weirdly almost exactly the same amount each time. I have a gps time server and most of the log events correspond with when the sync happens. As far as i can tell the gateway isnโ€™t running out of memory, and there is no anti virus or vulnerability scanning on this machine. Does anyone have any idea what may be causing this? Iโ€™ve heard that it could be hardware related, but do not know how one would begin diagnosing that. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 12, 2025, 11:03pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/2 "2025-09-12T23:03:02Z")
One or more hardware clocks are out of sync with each other. The OS is reporting to Java "hey, your time jumped backwards ~200 seconds", and Java is dutifully responding. The 'clock drift' warning in Ignition is just a symptom of that underlying problem. ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 12, 2025, 11:07pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/3 "2025-09-12T23:07:58Z")
I understand that, but how would one begin to determine the underlying problem? Iโ€™ve used these GPS time servers before without issue, so i am leaning towards it being on the server end. The most recent sync was 10am today and i can already see the os time is 3 seconds off. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2025, 11:13pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/4 "2025-09-12T23:13:15Z")
That seems pretty fast... CMOS battery or problem with hardware RTC? Not sure... edit: also some advice here about an alternative to W32Time, though it may not actually be your issue: [Critical ClockDriftDetector error - #5 by JordanCClark](https://forum.inductiveautomation.com/t/critical-clockdriftdetector-error/100055/5) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 12, 2025, 11:20pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/5 "2025-09-12T23:20:24Z")
> [@josborn](#): > > the underlying problem? That would be "using Windows". It corrects its clock with time warps. If the machine's rtc is drifting, you get regular warps as NTP works. Linux _slews_ its clock to make corrections, keeping it moving forward without discontinuities. Now, say it with me: "deploying MS Windows in production is engineering malpractice". ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 12, 2025, 11:20pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/6 "2025-09-12T23:20:33Z")
I thought the cmos battery only would affect the time at startup? This server very rarely sees a restart. I have a redundant gateway that also syncs with the same GPS time server and that one appears to be also generating the clock drift warnings but a positive amount. I am now more confused. ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 12, 2025, 11:23pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/7 "2025-09-12T23:23:42Z")
> [@pturmel](#): > > Now, say it with me: "deploying MS Windows in production is engineering malpractice". I completely agree, but our IT is VERY resistant to anything not Microsoft, though i have been pushing the issue. I am more concerned by the amount of the drift and that it may be an indicator of potential hardware failure. I am trying to get these servers replaced soon in any event. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 12, 2025, 11:25pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/8 "2025-09-12T23:25:19Z")
Just guessing about why your clocks might be drifting so quickly. Windows time corrections are warps, so if you are drifting a lot between the syncs then what you're seeing is expected. Speed up the syncs, try alternate NTP service (linked), or I guess try to figure out why time is drifting out of sync so quickly ๐Ÿ˜• ---
**Author:** ![David\_Stone](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/david_stone/32/79749_2.png) [@David\_Stone](https://forum.inductiveautomation.com/u/David_Stone)\ **Post date:** [September 12, 2025, 11:27pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/9 "2025-09-12T23:27:11Z")
According to Stack Overflow, any time updates from the windows end should be in the logs: You can read the [Windows Event Logs](https://learn.microsoft.com/en-us/windows/win32/eventlog/event-logging) and look for changes to system time. (System time changes are one of the system events that are automatically logged.) For example, I just tweaked my system time by a few seconds and the following appeared in the System Event log: > Information 10/21/2011 11:16:26 AM Kernel-General 1 None > > The system time has changed to โ€Ž2011โ€Ž-โ€Ž10โ€Ž-โ€Ž21T16:16:26.000000000Z from โ€Ž2011โ€Ž-โ€Ž10โ€Ž-โ€Ž21T16:16:26.000000000Z. ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 12, 2025, 11:41pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/10 "2025-09-12T23:41:41Z")
They do show in the log, though interestingly there are 2 time change events at the same time (it doesnโ€™t appear the event log is more granular than to the second though). The first one was a miniscule shift and the second was approximately 3.5 minutes which corresponds with the clock drift warning in ignitions log. ---
**Author:** ![David\_Stone](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/david_stone/32/79749_2.png) [@David\_Stone](https://forum.inductiveautomation.com/u/David_Stone)\ **Post date:** [September 12, 2025, 11:50pm UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/11 "2025-09-12T23:50:07Z")
Maybe increasing the poll rate for the NTP server would make the warps much smaller, VMware recommendation is 900 seconds (15min) because of the nature of VMs, so maybe on a bare metal server that would help? > **[Timekeeping best practices for Windows, including NTP](https://knowledge.broadcom.com/external/article/315346/timekeeping-best-practices-for-windows-i.html)** ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 13, 2025, 12:01am UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/12 "2025-09-13T00:01:16Z")
When VMs are involved, there can be conflicts between hypervisor and guest if both are running time sync. (In the Linux world, it is common to have the hypervisor track an upstream time source and provide a clock driver to the guest that transparently locks them together.) ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [September 13, 2025, 1:41am UTC](https://forum.inductiveautomation.com/t/possible-cause-of-significant-clock-drifts/110595/13 "2025-09-13T01:41:04Z")
I did read some about that, there is no VM involved in this case.