Windows-based NTP servers and non-Windows-based clients

Question

Hello everyone, I don't quite understand the behaviour of the root dispersion of Windows NTP servers. I would like to set up a network of Windows-based and non-Windows-based devices. I would like to define a computer with Windows 10 (Enterprise LTSC version 1809) as the NTP server that is to supply non-Windows-based devices with Chronyd time service with a synchronised time. However, the computer is only a secondary reference and receives its time as a client from an external Windows NTP server. Unfortunately, this secondary server receives the time with too high a root dispersion (~10s fluctuation). According to the manufacturer, the devices with Chronyd time service that are supposed to connect to this time server only accept a root dispersion of less than 3s. How does the root dispersion generally behave in such an architecture? Is the root dispersion passed through over several levels or does it add up over several levels? Is it possible to forward the root dispersion on the secondary server with a value less than 3s without adjusting the root dispersion of the primary server? Maybe you can enlighten me about the behaviour or have an idea how I could implement this scenario. Best regards Tobias

Answer 1

Thank you for the fast reply. I now understand the concept more clearly. Regarding to your recommended solutions. Solution 1 and 3 are not directly practicable for me. What windows version offers improved NTP functionality and lower dispersion? In solution 4, what do you mean by intermediate server? Could this also be implemented with the current Windows NTP server? Can you recommend a helpful NTP tracking tool?

Answer 2

Understanding Root Dispersion in a Windows NTP Server Hierarchy

Root dispersion in NTP refers to the difference in time between the reference clock and the client's local clock. In your case, you're concerned about the root dispersion being too high (~10s) on your secondary Windows NTP server (Windows 10 LTSC 1809) serving non-Windows devices with Chronyd. Adding more layers: Root dispersion typically does not accumulate across multiple levels. Each client calculates its own root dispersion based on its direct connection to the server, not including the parent server's dispersion. So, your non-Windows clients with Chronyd should only consider the dispersion between themselves and your secondary server (~10s). Challenge: However, Chronyd seems to have stricter tolerance than most clients, accepting only a root dispersion below 3s. Unfortunately, you cannot directly lower the root dispersion reported by your secondary server without manipulating the actual time source. Adjusting registry values may not work reliably and could introduce issues with the primary server's synchronization. Possible solutions:

1. Replace the primary server: If possible, consider switching to a more accurate primary server with a lower root dispersion.
2. Upgrade your secondary server: Newer versions of Windows might offer improved NTP functionality and potentially lower dispersion.
3. Adjust Chronyd configuration: While not ideal, you could explore modifying Chronyd's configuration to tolerate a higher root dispersion. This might require researching specific settings and could compromise time accuracy.
4. Implement an intermediate server: You could introduce another NTP server between your secondary server and the Chronyd clients. This intermediate server would directly synchronize with the primary server and then rebroadcast the time with a lower dispersion value acceptable for Chronyd. This option requires additional configuration and hardware resources.

Additional Notes:

• Ensure proper NTP configuration on all servers and clients, including accurate timezone settings and appropriate poll intervals.
• Consider utilizing NTP monitoring tools to track synchronization performance and identify potential issues.
• Research best practices for implementing NTP in mixed Windows and non-Windows environments.

Remember, manipulating synchronization mechanisms should be done with caution, as inaccurate timekeeping can significantly impact various system functionalities. I hope this clarifies the concept of root dispersion and provides some solutions for your specific scenario. Feel free to ask further questions if needed!

Answer 3

1. Improved NTP functionality in Windows versions:

Unfortunately, specific information on improved NTP functionality with lower dispersion is limited across Windows versions. Newer versions might have slight improvements, but significant jumps in accuracy are unlikely. It's more about overall system stability and network conditions impacting dispersion than major version differences. 2. Intermediate server implementation: Yes, you can implement an intermediate server with your current Windows NTP server. This server would act as a relay between your secondary server and the Chronyd clients. Configure it to synchronize directly with the primary server and then provide its own time signal to the Chronyd clients with a lower, manipulated dispersion value (within Chronyd's tolerance). Here's how you can achieve this:

• Windows Time Service: You can create an additional NTP server on another Windows machine within your network. Configure it to synchronize with your secondary server (the one with ~10s dispersion) and set its "AnnounceFlags" registry key to 0x5 (always time server and reliable). This makes it appear as a reliable source with its own lower dispersion value to Chronyd clients.
• Third-party NTP server software: Consider tools like ntpd (available for Windows) or Chronos. These open-source options offer more granular control over dispersion manipulation and might be easier to configure for your specific needs.

3. NTP monitoring tools: Several excellent NTP monitoring tools can help track synchronization performance:

• Net Time Monitor: A built-in Windows tool providing basic monitoring functionality.
• NTPQuery: Freeware tool offering detailed information about NTP servers and clients.
• MRTG (Multi Router Traffic Grapher): Open-source tool for graphical network performance monitoring, including NTP.
• Observium: Comprehensive network monitoring platform with NTP specific tracking.

Remember, manipulating dispersion values should be done carefully as inaccurate timekeeping can cause issues. Ensure you understand the potential consequences and only adjust dispersion as a last resort after exploring other options. Additional tips:

• Check the primary server's configuration and network connection for potential sources of high dispersion.
• Minimize network jitter and latency between your servers and clients for improved accuracy.
• Consider adjusting Chronyd's configuration slightly to increase its dispersion tolerance if possible.

I hope this additional information will help you Tobias and implement a workable solution for your NTP server hierarchy. Feel free to ask any further questions you might have!

Answer 4

I think the architecture with the intermediate server is what I already tried. But this didnt work for me. For test purposes I set up a primary NTP server who runs with local CMOS time. He is the Stratum 1 with local clock dispersion of 10. (IP 192.168.0.160) Then I set up a second NTP client who synchronizes its time with the primary server (IP 192.168.0.105) Pic1.png After that the client should also run as NTP server who publishes its time (with clock dispersion of 2) to the Chronyd clients. Here is the configuration of this secondary server. Pic2.png After that I connected one Chronyd device into the network and defined the secondary server as its time source. I monitored the NTP network traffic with Wireshark between the secondary server and the Chronyd client (192.168.0.159) and it seems like the secondary server publishes its synchronized time also with a clock dispersion of ~10. Pic3.png Maybe I did something wrong in the configuration of the second NTP server or something else. The Chronyd client does not accept the time source of the secondary reference.

Answer 5

I can provide a comprehensive step-by-step guide to fix the issue with your NTP server reporting the expected Root Dispersion value to the Chronyd clients. Here's what we need to know first:

1. Verify LocalClockDispersion setting:

• Please confirm the exact value of the LocalClockDispersion key in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters.
• Ensure it's set to 2. If it's not, set it to 2 and restart the Windows Time service with net stop w32time followed by net start w32time.

2. Recapture NTP traffic:

• Use Wireshark to capture NTP traffic again after setting or verifying the LocalClockDispersion value. Focus on packets from the secondary server (192.168.0.105) to the Chronyd client (192.168.0.159).

3. Analyze results:

• Check the Root Dispersion field in the captured packets. If it's still around 10, proceed to the next steps.

4. Further troubleshooting:

• If the problem persists, try these advanced steps:
  • Set LocalClockDispersion temporarily to a slightly higher value (e.g., 3 or 4) and then back to 2, sometimes this helps registry changes take effect.
    • Review other relevant registry keys related to NTP server configuration in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. Look for any conflicting settings or inconsistencies.
      • Consider using a different NTP server software on the secondary server to see if its dispersion handling differs.
        • Implement an intermediate server between the primary and secondary servers, configured to report a lower dispersion and act as a relay.
        5. Monitor and confirm success:
        • After trying any of these solutions, recapture NTP traffic and verify if the Root Dispersion reported by the secondary server has changed to the desired value of 2. If so, it indicates the issue is resolved.
        Additional tips:
        • Make sure your Chronyd client version supports a Root Dispersion of 2 or higher.
        • Consult Chronyd documentation for specific configuration options affecting how it interprets and validates dispersion values.
        • Maintain accurate time synchronization throughout your network for optimal system performance.
        Remember: I'm here to guide you through these steps. Feel free to ask any questions you may have along the way. We'll work together to fix this issue