Top of Page

Domain Time II
Version 5.2

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.

    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.

    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 or CDMA 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 you will be using the NTP and/or DT2 protocols
      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 minimum 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 server included as a sanity-check.

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

    • If you will be using PTP (IEEE 1588-2008/1588-2019)
      PTP provides the best accuracy when connecting to a hardware-based Grandmaster clock on the same subnet.

      You should have at least one other machine capable of becoming Grandmaster online for redundancy. PTP using the Default or Enterprise profiles provides for a master election among available machines should the current Grandmaster be offline. PTP using the Telecom profile uses a configured list of possible masters. Domain Time Server can be configured to be one of these backup master clocks for the Default or Enterprise profile (see How to configure Domain Time Server as a PTP Master). Domain Time Server cannot be a Telecom master. Domain Time Client cannot become a PTP master of any flavor.

      All Domain Time Servers or Clients running PTP should also be configured to have at least one fallback NTP/DT2 time source (see Configuring Domain Time II for PTP).

  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.

    In general, the best processors/chipsets for time synchronization are Intelís Core i7 line (or later) or Xeon E7 line (or later). Earlier chips are not as stable or as precise as the newer models. The newer processors also have an invariant timestamp counter, which allows Domain Time II to measure the passage of time accurately regardless of SpeedStep or other power-saving mechanisms. Issuing DTCHECK /cpuid from the command-line will show you whether or not your processor supports an invariant TSC.

    Win8/2012 or newer versions are preferred and are more predictable than Vista, Windows 7, or Windows 2008 for high-accuracy timing. The older XP/Server 2003 platform is also more stable than the problematic Vista/Win7/2008 versions.

    Virtual Machines
    In addition to the problem with heavily-loaded systems mentioned above, virtual environments (VMWare, Hyper-V, etc.) often have significant issues in servicing the clock in a timely manner, making them less than ideal for highly-accurate time synchronization. Domain Time will help you acheive the best synchronization possible on virtual systems, but you should be aware of the limitations. You can only determine if a virtual system will perform to your expectations by testing in your environment under your normal workloads.

    • In general, Domain Time Server should be run from a physical machine, if possible. 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.) give less accurate results when executed from a virtual guest. These should be run on physical machines, if possible.

    • 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 PTP, etc.). See the protocol table below.

    • Domain Time uses standard IP networking calls, made via the WinSock stack on Windows and the standard TCP/IP stack in Linux. Traffic therefore conforms to IP protocol standards, including use of ephemeral source ports for originating traffic directed at remote target ports. You should be sure your firewall(s) permits traffic orginating from ephemeral ports directed toward the defined listening ports in the protocol table below.

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

    • Domain Time components work best when able to transmit multicasts to discover machines on other subnets, so you will want to allow multicast traffic between your subnets, even if you will be using unicast protcols to synchronize the time. Note: A multicast-capable router must be present on each subnet and configured to pass the multicast traffic. Servers and Clients must be configured with sufficient TTL/Hop Count settings to cross the number intervening routers/switches. Some Domain Time components may also use broadcasts to local subnets and/or directed broadcasts to remote subnets for discovery purposes. See Network Discovery.

    • If using the PTP protocol, Domain Time will use multicasts, or a combination of multicasts and unicasts (if using the Hybrid or Enterpise profiles). If you use the PTP Telecom profile, communication is done solely using unicast. Domain Time can also transmit DT2 and NTP time packets using multicast and broadcasts, if desired. See Broadcasts and Multicasts for more information.

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

    • Some functions of Domain Time components (such as remote installation/upgrade/configuration) require Windows Networking file and remote registry 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.

    Note: As of Version 5.2.b.20150828, Domain Time supports automatic management of the Windows Firewall to allow access to the required time protocol and control ports. See Auto-Manage Windows Firewall Settings for detailed information.

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

    Protocol Default Port/Address Type
    DT2 9909 UDP and 9909 TCP
    (Required for all Domain Time Components)
    Time sync, auditing, and control messages
    DT2 Multicast IPv4:
    IPv6: FF05::9909
    Network discovery
    (optional broadcast time sync)
    DT2 over HTTP
    80 TCP
    Time sync, stats webpage on Server,
    Version update checking
    SNMP: RFC 1769
    v3: RFC 1305
    v4: RFC 2030
    123 UDP
    Time sync
    NTP Multicast IPv4:
    IPv6: FF05::101
    Network discovery
    (optional broadcast time sync)
    PTP v2.0 (IEEE 1588-2008)
    PTP v2.1 (IEEE 1588-2019)
    319 and 320 UDP
    Time sync
    PTP v2.0 (IEEE 1588-2008) Multicast
    PTP v2.1 (IEEE 1588-2019) Multicast
    IPv6: FF05::181
    IPv6: FF02::6B
    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

    Audit Server Standby-mode Replication

    DT Status 9911 UDP and/or 9911 TCP Domain Time Service Status Monitor


Next Proceed to the Recommended Configurations page
Back Back to the Changelogs page

Domain Time II Software distributed by Microsemi, Inc.
Documentation copyright © 1995-2024 Greyware Automation Products, Inc.
All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.