This document explains when to configure Domain Time Server to provide regular broadcast time announcements to the entire network.
Domain Time II Servers and Clients can be configured to use Heartbeats (using the Domain Time II UDP protocol) and/or NTP Broadcasts
(using the NTP UDP protocol). Because there are important consequences to network bandwidth, security, and robustness when
using either type of broadcast time, these options are disabled by default. In addition, Broadcast Time does not
scale well beyond a single subnet, and doesn't offer any redundancy in the event the broadcasting server becomes unavailable, so
it should only be implemented when there is sufficient reason to outweigh the disadvantages.
By default in the Domain Time II hierarchical Master-Slave-Client configuration, the Master server
will notify Slaves of any changes, and the Slaves will notify their Clients. In
this way, changes at the Master propagate rapidly throughout the entire network with
a minimum of network traffic. Clients are smart enough to detect whether or not
there are any Slaves. If no Slaves are found, a Client will respond to the Master's
changes without waiting for a Slave to signal the change. In addition to the
propagation of changes, each Slave and Client follows its own internal schedule
in checking with its server from time to time.
In this mode of operation, broadcast time is not recommended.
Operation without a Hierarchy
When no Master time server exists (i.e., in a workgroup where no machine is a PDC),
the only kind of Domain Time Server you can have is an Independent Server. An
Independent Server serves the time to any Client who asks for it, and broadcasts
a Level 3 cascade signal when its own time changes. Level 3 triggers are ignored
by Clients if a Master or Slave exists, otherwise the Clients will sync with the
In this mode of operation, broadcast time is not recommended.
When is Broadcast Time needed?
Broadcast time may be needed if there are third-party clients on the network that can only respond to NTP broadcasts.
Broadcast time may also be necessary in environments where very strict timing beyond what the
normal trigger/cascade method can provide is required (such as with lab test or data collection equipment). The
extremely low-overhead Domain Time II Ultra Thin Client
is provided for use in those instances.
Broadcast Time Operation
When the Heartbeat or NTP Broadcast pulse is enabled, Domain Time Server will send out a
broadcast signal at regular intervals. The interval may be as short as three
seconds, or as long as 24 hours. Any Domain Time Server (Master, Slave, or
Independent Server) may be configured to provide Broadcast Time. The broadcast
pulse may be sent to multiple subnets simultaneously.
Enabling Broadcast Time
A Server normally ignores Heartbeat and NTP Broadcast time pulses. Each Server will continue synchronizing its
own time based on how it is configured, and continue sending Level 1, 2, or 3
cascade signals as needed. The broadcasted pulse is provided in addition to normal
checks and cascaded changes. (You can configure servers to accept broadcasted time by changing settings
in the registry; however, we recommend against setting servers to receive broadcast time.)
You should never have more than one server
(whether Domain Time II Servers or other third-party servers) providing Heartbeats or NTP broadcasts on the same network! Severe
adverse consequences to your network's time may result, including the potential for clock jumps and reversals.
Differences between Heartbeats and NTP Broadcasts
Heartbeats come in two flavors; Heartbeat (Advisory Only) or Heartbeat (With Time Data). Domain Time version 2.5 components only understand the Advisory Only flavor
whereas Version 3.1 and later components can use either flavor. Versions starting with 3.1 include the special
Ultra Thin Client designed specifically to use the Heartbeat(With Time Data) and
- Heartbeat (Advisory Only) behavior
When a Full or Thin Client receives a Domain Time II Heartbeat pulse, it will immediately synchronize with the normal server it was set (or has discovered)
to use as its time source, which is not necessarily the machine providing the pulse. The main advantage to this method is that it does not
compromise the security of your time distribution hierarchy, since the clients will not use an unauthorized time source as a result of the Heartbeat.
This method results in somewhat higher overhead and network traffic than the other Broadcast Time types since the Client must send a request to its
server and wait for a response each time a Heartbeat is received. Only Full Clients and Thin Clients
can respond to Advisory Only Heartbeats. Ultra Thin Clients cannot use this Heartbeat type.
- Heartbeat (With Time Data) behavior
Full and Thin Client respond to a Heartbeat (With Time Data) pulses in exactly the same manner as they do Heartbeat (Advisory Only) pulses. This type of pulse
includes time sync data in the broadcast packet itself specifically for use by the Ultra Thin Client. Unlike the Full and Thin Clients, the Ultra Thin Client
cannot contact a server on its own to obtain the time, so an Advisory Only pulse is useless to it. Instead, the Ultra Thin Client immediately sets its time to
match the time included in the broadcast packet.
This results in significantly lower overhead than the Advisory Only Heartbeat, since
no additional traffic is necessary to obtain and synchronize the time. However this does make unconfigured Ultra Thin Clients susceptible to being interfered with by a
rogue server sending out conflicting broadcasts. See the Ultra Thin Client
documentation for instructions on securing the client.
- NTP Broadcast Behavior
NTP Broadcasts are similar in function to the Heartbeat (With Time Data). They included time sync data in the broadcast packet, so they are low-overhead
compared to Heartbeat (Advisory Only), however, like Heartbeat (With Time Data), they, too, are susceptible to interference from competing broadcast sources when
incorrectly configured. The main advantage to NTP Broadcasts is that they are compatible with third-party time clients that require NTP Broadcasts.
When deciding which type of Broadcast Time to use, you need to weigh the advantages and disadvantages of each. If you require tamper-proof synchronization and
are willing to sacrifice some accuracy and network bandwidth, Heartbeat (Advisory Only) is your choice. If you require the ultimate accuracy, Heartbeat (With Time Data) is the one
to use. If you have third-party clients that require NTP Broadcasts, then NTP Broadcasts is your choice. Of course, you may decide to provide your chosen flavor
of Heartbeat as well as NTP Broadcast if you wish.
Domain Time II Server version 3.1 and later allow configuration of Heartbeats and NTP broadcasts from the
Broadcast Time tab page of the Server's Control Panel applet. Domain Time II versions prior to version 3.1 can only enable the Heartbeat and NTP broadcast functions
by making changes to the registry.
Versions of Domain Time II starting with version 3.1 include the Ultra Thin Client,
which is a special broadcast-listener client. The Ultra Thin Client can respond to both NTP Broadcasts and the Heartbeat(With Time Data) broadcasts with no additional
configuration necessary. Note that it cannot respond to the older Heartbeat(Advisory Only) broadcasts.
By default, the Thin Client responds to Heartbeats (Advisory Only) without any additional configuration. The Full Client may be set to
accept or ignore both NTP Broadcasts and Heartbeats using the control panel applet.
You may also change the broadcast behavior of components by setting their appropriate registry value(s). See these pages for details:
Technical Note: Heartbeats and NTP Broadcasts are not sent at precision intervals;
the broadcast procedure is a low-priority background task that can be interrupted
or delayed by other demands on the server. Clients use the arrival of a Heartbeat
pulse as a trigger that they must synchronize, and if NTP or DT2 with time data broadcasts are used, they match their time
to the time included in the broadcast time packet; they do not determine their time based on
the regularity of the pulse itself. Therefore slight imprecisions in the rate of the broadcast have
a negligible effect on accuracy. Broadcasts pulses will never be sent more often
than the interval you set.
Caution: Do not set the Heartbeat or NTP Broadcast Rate any lower than you absolutely
must. Depending on the number of clients and your network topography, this can cause excessive
Changes you make to the Heartbeat or NTP Broadcast Rate settings take effect immediately. You
do not need to reboot the machine or restart any services. (If you decrease
the rate, the server won't notice the change until the previous period has elapsed.)