NetBurner Community Forum

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.

Here are some example w32tm stripchart logs taken from the PC that the PK70 NTP server is attached to

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

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

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?

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.

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?

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.