I have a Windows 7 and two Linux (Ubuntu 16.04) computers (W1, L1 & L2) connected via WiFi - a wired connection is unfortunately not possible. The Linux computers run chrony for time synchronization, L1 is set as source on L2, that works perfectly fine. The clocks should be as close together as possible, a 50 ms offset would already start causing problems. But for the Linux systems using chrony that's no problem at all. Now I also have to sync the time on W1 to L1 and unfortunately there is no chrony available for Windows. So I took this script here with the L1 IP as peer: https://gist.github.com/thedom85/dbeb58627adfb3d5c3af One-time synchronization works, but there are some flaws:
- The by far most problematic one: The time on the Windows system drifts away from the Linux time pretty quick. The drift is roughly about 1 s per 10 minutes on average. The easy solution - just re-syncing the clocks frequently - doesn't work due to problem 2 and 3
- On the Windows system the sync only succeeds if there is a major time offset to the time master. If It's just a few seconds no sync happens.
- On the Windows system the sync only gets applied after running the script, then disconnecting from the WiFi and connecting again. The clock jumps at the very moment the connection is established again.
Are there any ways to solve these problems or are there better approaches? Unfortunately I can't just steer all clocks to some high accuracy internet timing servers or GPS time since at least the Windows system is never connected to the internet and the Linux systems also can't rely on their internet connection. At first I thought problem 1 might be caused by chrony steering the L1 clock away, but deactivating chrony after the initial sync doesn't seem to have any effect on this problem.
Here are some pictures showing the problem. W1 constantly sends messages to L2 with the current L1 time, L2 adds his timestamp on arrival and the plot shows the difference between both timestamps as observed by L2.
EDIT: L1 and L2 are both battery powered - both by the very same source. Since solely the CMOS battery should be responsible for the RTC I didn't think that this might cause any problems. However it turned out that it is. Powering these computers by AC (so AC -> AC/DC converter -> computer instead of battery -> DC/DC converter -> computer) reduces the drift significantly. But it's still not good enough:
EDIT2: Solution / Workaround I disabled the crappy Windows time service (w32time) and installed a port of the Linux NTP program instead. With quite aggressive poll rate settings this works fine:
SetSystemTime()
with full subsecond resolution. Since you originally posted on stackoverflow.com, I presume that you'll be able to handle the programming.