PK70 NTP Server Offset Drift on Windows LAN

Discussion to talk about hardware related topics only.
Post Reply
Mannion2k
Posts: 6
Joined: Tue Apr 09, 2024 11:00 am

PK70 NTP Server Offset Drift on Windows LAN

Post by Mannion2k »

I am using a PK70 NTP server as a stratum 1 NTP server time source for a Windows system running on a LAN. The system requires all PCs on the LAN to be consistently and robustly synced to within 5 milliseconds during system operation. An accuracy of < 1ms offset across all machines is preferable.

The PK70 is directly attached to a PC on the LAN. The satellite receiver has good, clear sky access. In local offsite tests the PK70 produced promising diagnostic results.

In operation, installed on site, the system experiences steady, consistent drift in the order of 15-20 microseconds / second.
Mannion2k
Posts: 6
Joined: Tue Apr 09, 2024 11:00 am

Re: PK70 NTP Server Offset Drift on Windows LAN

Post by Mannion2k »

Here are some example w32tm stripchart logs taken from the PC that the PK70 NTP server is attached to
Mannion2k
Posts: 6
Joined: Tue Apr 09, 2024 11:00 am

Re: PK70 NTP Server Offset Drift on Windows LAN

Post by Mannion2k »

w32tm stripchart output for time.windows.com
delay is inconsistent and often > 0.1s
offset is drifting
17:58:12 d +00.0329220s o +00.1005369s
17:58:14 d +00.0445815s o +00.1041230s
17:58:17 d +00.0315021s o +00.1026311s
17:58:19 d +00.0380554s o +00.1041515s
17:58:21 d +00.0298747s o +00.0989348s
Mannion2k
Posts: 6
Joined: Tue Apr 09, 2024 11:00 am

Re: PK70 NTP Server Offset Drift on Windows LAN

Post by Mannion2k »

w32tm stripchart output for Netburner NTP server
delay is reliable
offset is drifting
18:16:15 d +00.0014044s o +00.1200124s
18:16:17 d +00.0014202s o +00.1196326s
18:16:19 d +00.0005767s o +00.1199734s
18:16:21 d +00.0013790s o +00.1195790s
18:16:23 d +00.0009545s o +00.1198901s
Mannion2k
Posts: 6
Joined: Tue Apr 09, 2024 11:00 am

Re: PK70 NTP Server Offset Drift on Windows LAN

Post by Mannion2k »

When left to log for an extended period the sync between the PCs drifts out to around 50 ms before correcting by a shift of around 50 ms. I assume that this is at the point where the offset triggers the immediate clock reset due to the check:
PhaseCorrection ≤ SystemClockRate ÷ 2 becoming false
This would suggest that the method to set the clock back slowly to address the offset is not working for this system configuration.

As part of an attempted fix I am currently scheduling a w32tm /resync task every minute. This seemed to have some short term impact on limiting the rate of the drift but has not resolved the overall problem.

As a simple check I have found that I can correct the offset of any of the PCs by manually forcing a reset to the server time:
    1) Performing a manual reset of the system time via the Windows timedate.cpl tool so that it is offset from the server time by more than the 1 second MaxAllowedPhaseOffset.
      2) Performing a manual NTP resync using the Update Now option from the Windows timedate.cpl tool.

      I was wondering if anyone can suggest the probable cause of the problem and the best way of resolving it or otherwise finding a solution.

      Could it be that the Netburner is automatically finding reference internet time sources and being offset by the poor internet delay? If so how would I disable that behaviour?
      User avatar
      TomNB
      Posts: 574
      Joined: Tue May 10, 2016 8:22 am

      Re: PK70 NTP Server Offset Drift on Windows LAN

      Post by TomNB »

      Where is this check happening? On your windows client?

      "this is at the point where the offset triggers the immediate clock reset due to the check:
      PhaseCorrection ≤ SystemClockRate ÷ 2 becoming false
      This would suggest that the method to set the clock back slowly to address the offset is not working for this system configuration."

      I think that Windows uses a 50ms time tick for system time (could be wrong). How do you know it is not the windows client that is not updating the time correctly, or is that what you are describing above? I would not expect a time server problem to be different in one location vs another (as in your first test) if both locations have a good gps lock. Not sure I completely understand your post, just trying to get some clarity.

      If you force a re-sync on just one windows machine, does it have a different/more accurate time than the others? The time server will send the same packets to all clients, so that would indicate an issue with the client and sync.
      Mannion2k
      Posts: 6
      Joined: Tue Apr 09, 2024 11:00 am

      Re: PK70 NTP Server Offset Drift on Windows LAN

      Post by Mannion2k »

      Thankyou for your extremely prompt response. I apologise for the lack of clarity. I don't believe that the PK70 is not working correctly. I am trying to understand the problem with this specific network implementation utilising the PK70 in conjunction with the standard windows client.
      Where is this check happening? On your windows client?

      "this is at the point where the offset triggers the immediate clock reset due to the check:
      PhaseCorrection ≤ SystemClockRate ÷ 2 becoming false
      This would suggest that the method to set the clock back slowly to address the offset is not working for this system configuration."
      Yes this is the check performed by the windows NTP client.
      Windows Time service tools and settings
      https://learn.microsoft.com/en-us/windo ... abs=config

      Could the PK70 potentially be affected by other internet NTP time sources. There appears to be a poor delay in external web connectivity. Is the delay the problem as illustrated by the timing stripchart delay for time.windows.com? In normal circumstances this log for delay and offset would look more like this.

      w32tm stripchart output for time.windows.com (off site test)
      delay consistent and below 0.02s
      offset exhibits no drift
      17:56:56, d +00.0181758s o +00.0005824s
      17:56:58, d +00.0170330s o -00.0002416s
      17:57:00, d +00.0176360s o +00.0003190s
      17:57:02, d +00.0181050s o -00.0004547s
      17:57:04, d +00.0166731s o -00.0001094s


      How do you know it is not the windows client that is not updating the time correctly, or is that what you are describing above?
      Yes it is the windows client that is not maintaining the correct offset to the PK70 NTP time. Do you have any ideas why this may be the case given the timing logs?

      If you force a re-sync on just one windows machine, does it have a different/more accurate time than the others?
      Yes this does correct the time on the resynced machine. It is a client and sync issue. Do you have any ideas on how I could modify the current implementation to resolve the issue? Is it just a network/internet connectivity issue? Are the logs enough to confirm that this is the cause?
      User avatar
      TomNB
      Posts: 574
      Joined: Tue May 10, 2016 8:22 am

      Re: PK70 NTP Server Offset Drift on Windows LAN

      Post by TomNB »

      Hello,

      I do not know of anything offhand, but doing some searches show a ton of threads on the topic of windows client ntp sync and drift. I'm sure you've already been doing that, but here is one link: https://www.reddit.com/r/sysadmin/comme ... vers_time/

      Other than sending the NTP packet when requested, the NTP server has no other influence on clients.
      Post Reply