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.
- 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).
- 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.
- 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: 239.192.99.9
IPv6: FF05::9909
|
Network discovery
(optional broadcast time sync)
|
DT2 over HTTP
|
80 TCP
|
Time sync, stats webpage on Server,
Version update checking
|
NTP/SNTP
|
123 UDP
|
Time sync
|
|
NTP Multicast
|
IPv4: 224.0.1.1
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
|
IPv4: 224.0.1.129
IPv4: 224.0.0.107
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
|
 Proceed to the Recommended Configurations page
 Back to the Changelogs page
|
|
