Domain Time II
Version 5.1 |
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.
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.
- 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.
- 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 time sync, control, and data streams between Servers, Clients, Management Tools,
and Audit Server. 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.
- 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).
- 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 need to transmit multicasts to machines on other subnets, so you will need to allow multicast
traffic between your subnets. Domain Time II (as of v5.1) only uses broadcasts on local subnets.
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.
Read these pages for more detailed information on firewalls, time protocols and ports, automatic discovery, etc.
 Proceed to the Recommended Configurations page
 Back to the Requirements page
|
|
