Planning for effective time distribution

This page describes how to choose time sources, select time server hardware, and how to prepare your network for using Domain Time.
 

1. Decide on your time source(s)
   Choosing good time sources for your network is the first implementation decision you need to make.

   Time sources should be located as close physically and network-topologically to the machines that use them as possible. A symmetrical, low-latency network connection between all machines will provide the most accurate time.

   Your network will need a top-level (trusted) source of time. This can be obtained from GPS receivers, cesium or other directly attached time servers, known good public Internet time servers, etc. On networks with no access to other time sources, you may decide to use a Domain Time Server as your trusted time source. If so, the internal system clock on the Domain Time Server will be the trusted time source.

   If your Domain Time Server(s) are connecting to the top-level time source(s) over a network, you will want to use multiple time sources to provide redundancy, increase the accuracy of your time, and to prevent wild time from being served should any of your time sources have an error. The best accuracy and redundancy is achieved by using at least three or more reliable time sources.

   Ideally, Domain Time Servers should be set to obtain at least three time samples from each time source during each time check. See the About Time Samples sidebar for detailed information.

   For example, an excellent configuration for your top-level time sources would be to have at least two GPS time servers located on a local LAN with at least one additional stable public servers included as a sanity-check.

   If you will be obtaining time from public time servers, please refer to the list of public time sources and abide by the published rules for each time source.

   ---

   IMPORTANT: It is essential that your time servers have sufficient performance, hardware, and OS stability to serve time reliably. The quality of the time sync on your network can only be as good as the accuracy of the time servers themselves.

   ---

    
   
2. Choose the right machine(s)
   Review the Software Requirements for Domain Time II.

   Due to how the system clock on operating systems are maintained, some systems are unsuitable for keeping accurate time. The quidelines below apply to both time servers and clients, however they are of particular concern to any machine you want to use as a time server.

   A good candidate machine for accurate timekeeping will have sufficient processor power, memory, and network hardware to be able to service the operating system and applications without hitting bottlenecks under load that cause delays in servicing interrupts, packets, and threads in a smooth and timely fashion. A heavily-used machine will typically have more clock-drift problems than a lightly-used system, so be sure that your machines are not experiencing bursty periods of excessively-high load or other performance problems.

   Some system motherboard designs, BIOS and firmware issues, multi-processor implementations, system/video/network drivers, or other system components can cause problems with servicing the system clock correctly and may require updates from the manufacturer. Be sure to check with your vendor(s) to be sure you are up-to-date with all necessary patches.

   Most modern operating systems and motherboards have integrated power-saving features. Unfortunately, many of these have serious detrimental effects on system timekeeping. In general, you will want to disable all power-saving features on all of your time servers, and also on any clients where precise timing is required.

   Virtual Machines
   In addition to the problem with heavily-loaded systems mentioned above, virtual environments (VMWare, Microsoft Virtual Server/Hyper-V, Xen etc.) have significant issues in servicing the clock in a timely manner, making them inappropriate for use as time servers in production environments.

   • Domain Time Server should not be used to serve time from virtual machines. This configuration is not supported. Also, any tools that calculate comparative time variances (such as Domain Time II Audit Server, Domain Time II Monitor Service, the Domain Time II Manager variance report, DTCheck utility, etc.) cannot be relied upon to provide accurate results when executed from a virtual OS. These should be run on physical machines.

   • Domain Time Clients may be run on an OS in a virtual machine guest, although you should be aware that regardless of the time service configuration, the clock will still have inherent inaccuracies. Any time-critical system should run directly on physical hardware.

     See this article from our knowledgebase for more information on use with virtualization systems.

    
   
3. Prepare your network to pass the necessary traffic
   Your network routers, switches, and firewalls must be able to pass the proper traffic to allow Domain Time to function correctly. Here are some basic guidelines:
   • Domain Time II uses the DT2 (Domain Time II) protocol to communicate not only time sync data, but control messages and data streams between Servers, Clients, Management Tools, and Audit Server.

     IMPORTANT: You should always configure your internal network to pass both port 9909 UDP AND port 9909 TCP traffic bi-directionally between all subnets, even if you will be using a different protocol to sync the time.

   • If you will be obtaining time from an external time source (such as from a public time server) through a firewall using the DT2 protocol, you may use either port 9909 UDP or 9909 TCP. UDP has lower overhead and latency than TCP so it tends to be slightly more accurate, however, some firewall administrators prefer to allow only TCP connections. DT2 also has a special "DT2 over HTTP" protocol available to allow synchronization with Domain Time II Servers over HTTP (default port 80), which can allow synchronization through most existing firewalls.

   • You will need to configure your firewalls/switches to pass any other time protocols you want to use (i.e. port 123 UDP for NTP, ports 319 & 320 UDP for PTPv2, etc.).

   • As of v5.1, Domain Time natively supports both IPv4 and IPv6. You may pass traffic over either version of TCP/IP.

   • Domain Time II components work best when able to transmit multicasts to machines on other subnets, so you will want to allow multicast traffic between your subnets. Domain Time II also uses broadcasts to local subnets by default.

     Domain Time can also transmit DT2 and NTP time packets using multicast and broadcasts, if required. See Broadcasts and Multicasts for more information.

   • Your internal network should have correctly configured and functioning Active Directory, DNS, WINS, and Windows Network browsing (if using NetBIOS).

   • Some functions of Domain Time components (such as remote installation/upgrade using Manager) require Windows Networking file access through administrative shares. Those programs or services must be run under a user account with sufficient administrative privileges to make such connections.

   • ICMP traffic (esp. PING) should be permitted to all machines.

   Domain Time components may use these network ports for various functions (default ports shown):
   

   Protocol	Port	Type
   DT2	9909 UDP and 9909 TCP (Required for all Domain Time Components)	Time sync and control messages
   DT2 over HTTP	80 TCP	Time sync, stats webpage on Server
   NTP/SNTP	123 UDP	Time sync
   TIME/ITP (RFC 868)	37 UDP and/or 37 TCP	Time sync (Server only)
   Daytime (RFC 867)	13 TCP	Time sync (Server only)
   DT Alert Control	9910 TCP	Domain Time Real-time Alert Sharing/Alert Viewer
   DT Status	9911 UDP and/or 9911 TCP	Domain Time Service Status Monitor

 Proceed to the Recommended Configurations page

 Back to the Requirements page