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.

Normal Operation

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 Independent Server.

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.

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.)

Warning:

---

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 NTP Broadcasts.

• 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.

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:

 Domain Time II Full Client Registry Settings
 Domain Time II Thin Client Registry Settings
 Domain Time II Ultra Thin Client Settings
 Domain Time II Server Registry Settings

Note: registry changes are only required if you wish Server to change its own time when receiving broadcasts. Sending NTP Broadcasts from server is enabled from the Broadcast Time tab page.

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 network traffic.

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.)