Top of Page

Serve the Time  Serve the Time
Domain Time II Server
Version 5.2

Use this page to set which time protocols are served by Domain Time II Server.

Note: If you see the Policy Applied Group Policy applied indicator in the lower-left corner of the applet, there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here. See the Active Directory page for more information on using Group Policies.

 

 Domain Time II on port 9909/udp and tcp 

DT2 Server Enabled
       Send IPv4 broadcasts
       Send IPv4 multicasts
       Send IPv6 multicasts

Bcast version:
Bcast interval:
  
HoursMinsSecs

This section controls whether Domain Time II Server will provide time using the Domain Time II (DT2) protocol.

    The DT2 protocol is a high-efficiency protocol optimized for time synchronization that also allows for bi-directional communication between Domain Time components using Domain Time control messages that enable advanced management and monitoring functions. This setting only controls whether Domain Time will respond to DT2 time requests and/or transmit DT2 time broadcasts or multicasts.

    These settings do not affect DT2 control messages. Even if the protocol is turned off on this page, Domain Time II Server will still send/receive DT2 control messages on port 9909 UDP and TCP. See the Advanced... Command Restrictions section of the Security Settings page for information on controlling command messages.

    When DT2 Server Enabled is checked, Domain Time Server will reply to either UDP or TCP time requests. UDP is an excellent choice for time packets, since it is connectionless and does not incur the overhead necessary to establish and tear down a full TCP session. TCP is often used for sending larger amounts of data in control messages. Your network will need to pass both port 9909 UDP and TCP packets in order to work correctly with Domain Time II version 5.x and above. See Installation Planning for more information.

    Should I choose DT2 or NTP? DT2 UDP sync packets tend to be smaller and therefore somewhat more efficient than NTP time packets. In normal networking applications, either protocol is a good choice. However, if you are attempting to achieve very high-accuracy, the difference in overhead between DT2 and NTP packets can become significant and you will want to use DT2 UDP whenever possible.

    DT2 Broadcasts/Multicasts

      The normal operation of Domain Time Server is to respond to unicast NTP time requests from time clients. This is a "pull" method of obtaining the time, where clients request the time on their own schedule. Domain Time Server can also be set to transmit NTP on a regular schedule. This is a "push" method of distributing time where clients listen for time packets from the server.

      The Broadcast and Multicast addresses used by Domain Time are configured on the Broadcasts and Multicasts page.

      The Send IPv4 broadcasts
             Send IPv4 multicasts
             Send IPv6 multicasts
      checkboxes on this page set the method used to transmit DT2 packets when using the "push" method of distributing time.

    • IPv4 Broadcasts are sent to the configured broadcast address (usually the local network). Broadcasts do not typically pass routers, so you will likely use this option only if your clients are on the same local subnet as the server. Broadcasts are deprecated in favor of multicast starting with version 5.x.

    • IPv4/IPv6 Multicasts are usually able to pass routers/switches without additional configuration and are therefore usually a better choice for transmitting heartbeat packets. Domain Time handles all of the details of joining the correct multicast group for the protocol for you. You may select IPv4 and/or IPv6 multicasts.

        Be sure the TTL (IPv4) or Hop Count (IPv6) settings on the Broadcasts and Multicasts page are set correctly so that multicasts reach your desired subnet(s). Multicasts are supported as of version 5.x.

        Bcast Version: selects whether a Broadcast pulse contains a timestamp (version 4) or not (version 3).

        If you select version 3, the Client will be triggered to synchronize its time when the pulse is received. It will then make a unicast request for the time from whatever Domain Time Server it is configured to use. Version 3 heartbeats are compatible with Domain Time version 3.1 and above.

        If you select Bcast version 4, the Server will include the current time in the broadcast time packet. Clients will set their time to the included timestamp and do not make any requests of a server. Version 4 heartbeats are compatible with Domain Time version 4.x and above.

        Multicasts always include the current time in the timestamp. This setting has no effect on Multicasts.

 

 NTP on port 123/udp 

NTP Server Enabled
       Send IPv4 broadcasts
       Send IPv4 multicasts
       Send IPv6 multicasts

Bcast version:
Bcast interval:
  
HoursMinsSecs

This section controls whether Domain Time II Server will provide time using the NTP protocol, either by unicast requests from clients or by broadcast and/or multicast.

There are special considerations for this setting when you are running on a Windows Domain Controller. See the What About Windows Time? sidebar for details.

    When NTP Server Enabled is checked, Domain Time Server will reply NTP UDP time requests. Your network will need to pass port 123 UDP packets in order to communicate with devices that use NTP.

    Although port 123 UDP is sufficient to pass time traffic, you will also want to pass DT2 control messages if you want to use many of Domain Time's advanced features. See the Network section of the Planning page for more information.

    When enabled, Server will also be able to respond to a subset of requests from the standard UNIX/Linux ntpq and ntpdate query utilities. See the ntpd Compatibility page for details.

    NTP Stratum

      By default, Domain Time selects an NTP stratum number based on on strata reported by its time sources (including PTP, which uses "StepsRemoved" to correspond, roughly, with NTP strata). Since Domain Time can use multiple sources with multiple protocols, there may not be an ultimate single stratum from which time was received. In these cases, Domain Time takes the highest-level stratum reported by all used sources, and adds one to derive its own stratum number. So, for example, if Domain Time obtains its time from a PTP grandmaster directly, it will report itself as stratum 2. If it receives its time from three NTP sources, two of which report stratum 1, and one of which reports stratum 2, Domain Time will report itself as stratum 3. If all three NTP sources reported stratum 1, Domain Time would report stratum 2, and so forth.

      If there are no upstream timesources (such as when you select the "Do not set this machine's time" radio button on the Obtain the Time page), Domain Time will assign itself stratum 15, which is the lowest valid stratum number. However, some NTP clients will refuse to synchronize with lower stratum levels. In this case, you will need to use the HKLM\SOFTWARE\Greyware\Domain Time Server\NTP Server Stratum registry key to assign a higher stratum, i.e. a registry value of 1 assigns stratum 1.

      Versions prior to 5.2.b.20150516, automatic assignment applied a default Stratum depending on the type of Server Role selected:

      • Master Server: Stratum 2
      • Slave Server: Stratum 3
      • Independent Server: Stratum 2

    NTP Broadcasts/Multicasts

      The normal operation of Domain Time Server is to respond to unicast time requests from time clients. This is a "pull" method of obtaining the time, where clients request the time on their own schedule. Domain Time Server can also be set to transmit time on a regular schedule (also referred to as "heartbeats"). Heartbeats are a "push" method of distributing time where clients do not obtain the time until signaled by the server.

      The Broadcast and Multicast addresses used by Domain Time are configured on the Broadcasts and Multicasts page.

      The Send IPv4 broadcasts
             Send IPv4 multicasts
             Send IPv6 multicasts
      checkboxes on this page set the method used to transmit NTP packets when using the "push" method of distributing time.

    • IPv4 Broadcasts are sent to the configured broadcast address (usually the local network). Broadcasts do not typically pass routers, so you will likely use this option only if your clients are on the same local subnet as the server.

    • IPv4/IPv6 Multicasts are usually able to pass routers/switches without additional configuration and are therefore usually a better choice than broadcasts. Domain Time handles all of the details of joining the correct multicast group for the protocol for you. You may select IPv4 and/or IPv6 multicasts.

        Be sure the TTL (IPv4) or Hop Count (IPv6) settings on the Broadcasts and Multicasts page are set correctly so that multicasts reach your desired subnet(s). Multicasts are supported as of version 5.x.

        Bcast Version: selects what NTP version the time packet reports for compatibility with various NTP implementations. The default value is 3, which should be correct for most situations. Don't select version 1 or 2 if you are using authentication.

 

  

DT2 over HTTP    Port:  tcp
       Allow clients      Allow browsers
       Allow servers      Serve DTLinux Updates
                                              Test Server

Domain time I (mailslots)

Select whether to enable the DT2 over HTTP and/or the Domain Time I (mailslots) protocols.

  • DT2 over HTTP

    This is a special time protocol that is communicated using standard HTTP packets. The typical port used is TCP port 80. (Note: some older versions of Domain Time shipped with this setting set to port 90 as the default)

      Since this protocol uses the same standard HTTP port used by web browsers, it can pass through most firewalls transparently. This can easily solve firewall connectivity issues for obtaining time.

      However, we recommend you only use this protocol for time synchronization if your firewall administrator is unable/unwilling to allow the regular Domain Time II protocol (UDP port 9909) or other native time protocols to pass the firewall. Due to the nature of HTTP and the variability of proxy configurations and load, the DT2 over HTTP protocol is subject to unpredictable latencies that can affect the accuracy of the time being sent. Also, many of the advanced features of Domain Time II such as remote control, monitoring, and upgrade/installation are not available using this protocol.


      CAUTION: Only one service can "own" the HTTP port 80 on a machine at a time. Domain Time II Server starts very quickly at boot-up. If the Domain Time II over HTTP protocol is enabled, it will very likely attach to port 80 before any other service can start (such as standard web servers like Microsoft's IIS). This will prevent the web server from responding correctly.

      If you are running Microsoft's IIS or another web server on your machine, you should change the Domain Time II over HTTP IP port to an unused number to avoid these conflicts.


      If you enable the DT2 over HTTP protocol, Domain Time Server can provide a compact DT2 over HTTP time protocol packet (if you have either the Allow clients and/or Allow servers checkbox checked).

      Web Page Stats Display
      Domain Time can also provide a special human-readable web page if you have the Allow browsers checkbox checked.

      Web Page Stats Display
      Web Page Stats Display   [Click for larger size]

      The web page provides a great deal of useful information about the status of the Domain Time II Server, and is a great way to monitor the operation of your servers from any machine with a browser. To view the webpage, enter the name or IP address of your Domain Time II server (plus ":" and the port number, if needed) into your web browser address bar, i.e. http://tick.greyware.com:80

      You can customize the appearance of the web page using standard HTML code. See the Customizing the appearance of Domain Time over HTTP registry entry on the Server Registry Options page for details.

      DTLinux Updates
      The Serve DTLinux Updates checkbox allows Domain Time Server to act as an alternate data source for DTLinux updates (Domain Time Manager must also be installed on this machine). The Test Server link will display the available DTLinux distribution files. Please see the UpdatingDTLinux.html file located in the DTLinux distribution files or in the
      /opt/domtime folder of your DTLinux system for full instructions.

  • Domain Time I (mailslots)

    Domain Time I is a proprietary protocol used by version 1.x of Domain Time.

      It uses LAN Manager's Mailslots function to obtain the time from a Domain Time Server. You will only need this protocol if you have any Domain Time version 1.x clients in use.

 

 Precision Time Protocol 

Allow IEEE 1588 PTP Master mode      Options

You may enable PTP Master mode operation by checking this box. Click the Options link to bring up the PTP configuration pages.

 

 NIST Daytime on port 13/udp or tcp 

NIST Daytime UDP Enabled
NIST Daytime TCP Enabled

NIST Daytime is an older, human-readable time protocol.

    Domain Time II Server will serve time via the Daytime protocol, but no Domain Time II component uses Daytime for time synchronization purposes. Domain Time II Server's Daytime string format defaults to the NIST standard (see below), but may be customized to other formats using a registry setting.

 

 TIME/ITP on port 37/udp or tcp 

TIME/ITP UDP Enabled
TIME/ITP TCP Enabled

TIME/ITP is another older protocol used by some legacy systems.

    Domain Time II Server will serve time via the TIME/ITP protocol for compatibility with Domain Time II version 2x - 4x, but as of version 5.x, Domain Time II does not use TIME/ITP for obtaining the time.

 

Next Proceed to the Domain Role page
Back Back to the Correction Limits 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.