In order to use Domain Time for Windows as a PTP Slave to an existing Master, you must make the following configuration choices on the Obtain the Time property page on the Domain Time applet:
Choose the Set this machine's clock by querying a list of servers radio-button.
On versions prior to 5.2.b.20150828, you must uncheck the Analyze time samples from all servers and choose the best checkbox to prevent skewing of the time by the additional sample analysis from sources other than PTP.
However, on current versions, you may leave this box checked, since non-PTP samples are now automatically excluded. This allows you to have better performance when falling back to DT2 or NTP sources without degrading the PTP performance in normal operation.
Uncheck the If all listed servers fail, try to discover sources automatically checkbox to prevent auto-discovery of NTP or DT2 time sources.
IMPORTANT: Specify at least one reliable non-PTP server (either NTP or DT2) in the List of backup time sources to use
field to act as fallback server(s). This way, when PTP hasn’t synchronized yet or when it fails because the master clock goes offline,
Domain Time will have another source for time. This also aids in quick recovery should an unexpected large excursion occur (PTP takes a
longer time to correct large variances).
Note: PTP does not begin synchronizing immediately when starting. It must listen to the network to detect the master clock, and must then calibrate to it before usable time samples are available to the Domain Time II clock management algorithms.
This means that for a period after startup, or if PTP sync is lost, Domain Time II will not be able to use PTP as a time source. Having a backup NTP or DT2 time source ensures the system has a good source of time in the interim. Also,
PTP can take a fairly long time to correct large variances, so having a fallback server avoids having a long training period for PTP to bring the clock into conformance.
On networks where you don't have any alternative sources of time other than the PTP Grandmaster, you may opt to check the
Accept First PTP Timestamp checkbox to accelerate
convergence from large clock disparities. There are important consequences to this, however. Please see the full description of this option below.
If your PTP Default or Enterprise profile Master is not on the same subnet as the Client, be sure the Multicast IPv4 TTL (Hop count for IPv6) settings on the
Client's Broadcasts and Multicasts property page are set
high enough to allow multicasts to cross intervening switches and routers. Typically you would set this value at least one higher
than the number of router hops involved. Note your Master must also have its router hops values configured to allow its multicasts to
cross any boundaries. When using the Telecom profile, hop count settings are irrelevant.
On the Logs & Status property page, enable a lazy write delay of at least 5 seconds. This helps prevent disruptions to accuracy from the logging process.
On the Timings property page, set both the Check Interval when able to get and correct the time
and Check Interval when getting the time fails settings to use the same fixed period; we HIGHLY recommend a Fixed schedule of every 1 minute.
Domain Time's PTP implementation is optimized for this setting. Do not set these
values lower than every 30 seconds when using PTP. Although these settings do not control PTP synchronization rates, they do affect
sample collection and control how often Domain Time synchronizes if falling back to DT2 or NTP, and also how often it records sync
status in the text logs and performs other alerting functions. Too short of a period may not allow PTP enough time to collect valid samples.
Check the Enable IEEE 1588 Precision Time Protocol (PTP) checkbox.
If you are going to be synchronizing using the Telecom profile, click the "Options" link and make the following additional
selections on the PTP Options dialog (otherwise, leave the options at the default settings):
Choose the "End-to-End Telecom Profile" from the PTP Profile dropdown list.
Set the PTP Domain to match the PTP domain configured on your Master, i.e. the G.8275.2 Telecom profile uses a default domain of 44.
Select the Only select best master clock from among those listed below radio button in the Best Master Clock Options section.
Enter the IP address of the Telecom master server(s) you want to use - one per line. Domain Time will subscribe to announce messages from
each listed server, and decide which to use based on their advertised quality. If all servers are equal, Domain Time will attempt
to use the servers in the order listed.
If your telecom server is non-standard, you may click the button to set Telecom-specific settings. Do not change these values unless your server requires them.
Click the Apply button to save your changes. Domain Time will then start listening for Master announcements, and will automatically calibrate and start
synchronizing with the Master. You may check the activity of the PTP conversation by clicking the Status and Graph links.
OPTIONAL: As of v5.2.b.20190701, Domain Time Client and Server support Windows NDIS software timestamping, which allows measurement of network stack delays.
Software timestamping is only available on Server 2019 (or newer) and recent updates of Win10/Win11. You may want to experiment with this setting
to see if it improves your accuracy. See the Use software timestamping section on the Advanced property page for more details.
Troubleshooting
The default PTP settings should be sufficient for Domain Time to synchronize with most Master clocks. However, you may encounter some network
issues or non-compliant Master servers that prevent synchronization. Here are some steps you can try:
Verify that multicasts are allowed on your network. See the Planning documentation for network requirements.
Ensure that there is an IGMP (if using IPv4) or MLD (IPv6)-enabled router or a switch attached to the same subnet as your PTP Master and Slaves. This function is also called IGMP Snooping.
IGMP/MLD is used to join multicast groups and provides the most robust multicast behavior. Unlike with unicast protocols like NTP, a direct cable connection to a clock with only a
crossover cable may not work. If you do try this, be sure all of your machines are booted and have working IP addresses before starting the Domain Time service. Direct-connection is not recommended.
Enable network communication through firewalls. You may quickly open all relevant time protocol ports in the Windows Firewall using the following command as Administrator from a command-prompt (Version 5.2 and later):
dtcheck -firewall:open -all
NOTE: Certain versions of Windows block these ports by default regardless of whether the Windows Firewall service is running. The Windows Firewall service must be started to run the above command. If the service is disabled, you must re-enable it temporarily to run the command, then re-disable the service if you wish.
Ensure that the following checkboxes are checked on the Network property page:
Initiate rebind and resync if IP address changes Enumerate multicast interfaces during IPv4/IPv6 bind Reply to multicasts using incoming interface if possible
To easily see which PTP masters are visible on your network, Click the Status link on the Obtain the Time property
page and then click the PTP Masters link at the bottom of the stats display. Available master servers will appear in this utility.
Select the master you want to use, and click the button.
This will often be able to automatically configure Domain Time with the correct settings to use that master.
You may also issue the following command from a command-prompt:
dtcheck -ptpmasters
Be sure you have not excluded the IP address of your PTP Grandmaster using the Best Master Clock Options settings.
If your machine is multihomed, you may need to restrict Domain Time to listen only on the proper subnet using the Listen only
on these addresses: list box on the Network property page.
Try relaxing strict IEEE 1588 requirements. Click the Options link to display the IEEE Precision Time Protocol Options
page. Then, click the button to display the IEEE 1588 Precision
Time Protocol Advanced Settings dialog page.
First, uncheck the Require strict IEEE 1588-2008 standard
compliance (recommended) checkbox. Test to see if this configuration now allows synchronization.
Next, uncheck the Require ptpTimescale (IEEE 15878-2008
section 8.2.4.8) checkbox. Test to see if this configuration now allows synchronization. Take care with this option. If unchecked,
your Master clock may be using a different timescale than expected, resulting in the time being off. Check with your clock manufacturer
to be sure the Master clock is using the correct timesecale. The PTP timescale is the preferred choice.
Specify a PTP profile if one isn't being autodetected. On the IEEE Precision Time Protocol Options page, you may use the
PTP Profile dropdown to specify the profile used by your Master clock.
Specify a defined Delay Transport option instead of "Auto-detect." Disable Unicast support if necessary.
Ensure the Clock Identity value is unique on your network. The default value is derived from the MAC address of your primary
network adapter during installation. You must change this value to a different guaranteed-unique value if the PTP master to which you
want to sync is on the same NIC and/or has the same Clock Identity. Otherwise, do not change this value.
As mentioned above, newer switches and routers may have PTP-awareness (such as those capable of acting as boundary clocks). Many of
these have had firmware bugs that actually interfere with proper PTP operation. If you are using such a device, try swapping in a
standard non-PTP capable switch to see if you can communicate properly. If so, contact your hardware vendor to obtain a fix/firmware
update.
If you are using PTP v2.1 authentication, temporarily disable authentication on the PTP Options dialog. If things then start
working, you need to verify that your authentication settings match your Master. Check the
Symmetric Keys property page to be sure your
SHA256 hash(es) match your Master, and that you are either using an SPP of 0 (wildcard) or the exact SPP being used by the Master.
Use the PTPCheck utility to verify your PTP
devices are providing management messages. Copy the program to various machines on either side of switches and routers to verify the
PTP traffic is being passed by your network equipment without interference.
Configurable Options
While PTP is designed to operate on the local segment without any configuration by the administrator, Domain Time II nevertheless exposes a few options for customization.
PTP Domain
Networks of clocks using PTP are separated into logical “domains,” or groups of clocks. Nodes will only respond to messages sent
to their domain. The domain is specified by a number, and the default domain is 0 (zero). Any number between 0 and 127 inclusive is a valid domain number.
If you change this setting on your master clock, you must change each Domain Time II machine to match.
As of version 5.2.b.20170101, you may use the Dynamic Domains feature by checking the Dynamic (allow any domain when slave) checkbox.
PTP Profile
The default operation of Domain Time II is to detect the delay mechanism used by the master clock. The options are:
Auto-detect
End-To-End Default Profile (00-1B-19-00-01-00)
End-To-End Enterprise Profile (00-00-5E-00-01-00)
End-To-End Telecom Profile (00-19-A7-00-01-00) - added as of v5.2.b.20180606. This option cannot be auto-discovered.
Peer-to-Peer Default Profile (00-1B-19-00-02-00)
Disable link delay measurement
Delay Transport
The default operation of Domain Time II is to test the master clock for unicast delay support and use unicast if possible. The options are:
Auto-detect
Unicast (hybrid mode)
Multicast (standard mode)
Note: If Auto-detect is selected for PTP Profile and/or Delay Transport, Domain Time will send a limited number of discovery Delay Requests.
If no response is received, it will stop sending requests until the next service restart (to conserve bandwidth). If you need Domain Time
to continue to send requests even if it never receives a reply, choose something other than Auto-detect for these items.
IPv6 Scope
The default operation of Domain Time II’s support for PTP over IPv6 is to listen and send on the site-local scope. You may override this to specify link-local scope instead.
Statistical options
Domain Time applies statistical analysis to acquired PTP sync and delay samples. In most cases, the default settings are optimal, however,
if both your PTP master and slaves are not on a stable, local subnet with low-latency you may find some improvement by adjusting these values.
Pay close attention to the results of your changes, as they can have adverse consequences on your accuracy, and even your ability to synchronize at all.
Use smoothing for meanPathDelay: Disable only if you have significant variable latency between your master and slaves. Cap latency at hectos: Ignores any samples with latency larger than this value. Do NOT use unless you have significant variable latency between your master and slaves. Enabling this setting can result in a complete inablity to synchronize. Use smoothing for delta calculations: Disable only if you have significant variable latency or timestamps between your master and slaves. Enable Trend Filter: On most machines, enabling this filter provides optimal synchronization, however, some machines may do slightly better with it disabled. Uncheck this box only if your machine is extremely stable and normally has an average delta of only a few microseconds. Coalesce PTP samples separately: Does not combine samples collected during the sync period into a single logged value, but logs them individually in Trace mode. Accept First PTP Timestamp after samples: Immediately steps or slews the clock to match the first observed PTP timestamp(s). The samples entry indicates the number of timestamps that must be received before the clock is corrected.
This option was only available via a registry setting in versions prior to 5.2.b.20200930. Older versions always stepped their correction.
Note:
You should enable this option ONLY in situations where you have no other time sources
available. Accept First PTP Timestamp may STEP the clock, either forward or backward,
if the time exceeds slew boundaries.
Accept First PTP Timestamp is designed for isolated networks, where only a PTP grandmaster
is available (i.e, no NTP or DT2 sources), and where the machine's startup time of day may
be wildly off. It will trigger at the start of the Domain Time service, or when a
resume-from-standby or clock-change signal is recognized. If no NTP or DT2 time sources
are configured and working, then Accept First PTP Timestamp WILL slew or step the clock.
Crosscheck with other sources if delta exceeds ms: If the delta (variance) between the slave and the master exceeds this threshold, Domain time will fall back to the NTP or DT2 time sources listed on the Obtain the Time property page.
There should always be at least one valid time source listed there. PTP is quite slow at correcting large variances both during startup and in the event of a large excursion. NTP and/or DT2 will recover much faster. Once the delta is back within tolerance, PTP will resume synchronization. You should not disable this option under most circumstances.
The Delay/Pdelay Request Interval and Announce Receipt Timeout Multipier values should be set to Automatic in almost all cases.
PTP v2.1. Authentication Options
As of v5.2.b.20190331, Domain Time supports PTP v2.1 authentication. These options allow you decide whether to use authentication
and whether or not to reject unsigned PTP messages. Please see the Domain Time PTP v2.1. Authentication knowledgebase article
for a detailed discussion of how Domain Time implements the v2.1 specification.
Notes:
Authentication requires the use of at least one SHA256 symmetric key shared between both the Master and Slave(s). Symmetric keys are configured on the
Symmetric Keys property page.
Message authentication can introduce a significant amount of overhead, decreasing PTP accuracy. You should enable authentication only if your environment requires the
additional security and enable only the minimum number of options. Typically, signing announces is the least invasive option.
Take extreme care when enabling any of the message rejection options, particularly if you are using more than one potential Master clock. Rejecting messages will prevent
Domain Time from becoming a Slave if any of your Master clocks do not sign their messages with the same options in a compatible fashion.
PTP v2.1. Authentication TLV processing enabled: Turn Authentication on or off. Reject unsigned Announces: If checked, Domain Time will reject any unsigned Announce messages. Reject unsigned Syncs/Follow-Ups: If checked, Domain Time will reject any unsigned Sync or Sync Follow-Up messages. Reject unsigned Delay Responses: If checked, Domain Time will reject any unsigned Delay Response messages.
Select best master by quality: If selected, Domain Time will use any master selected by the Best Master Clock (BMC) process, regardless of whether its announces are signed. Prefer signed Announces: If selected, Domain Time will give Masters that sign their announce messages higher priority in the Best Master Clock (BMC) process. Require signed Announces: If selected, Domain Time will ONLY use Masters that sign their announce messages. Use this option with care.
E2E Delay Request KeyId PTP Delay request KeyId
Use these dropdown lists to select the Symmetric Key ID being used by the Master to sign either End-to-End or Peer-to-Peer delay requests.
Only KeyIds you've configured on the Symmetric Keys property page will appear in the list.
In most cases, you will not need to configure this setting. Do so only if your Master requires it.
Best Master Clock Options
Domain Time II is a software-based implementation of PTP. The default operation according to the standard is for Domain Time II to discover
and synchronize with the best master clock available on the local segment. If that clock goes offline and another clock assumes the master role,
or if another clock claims to be more authoritative, Domain Time II will begin synchronizing to the new master automatically.
The standard behavior is sometimes undesirable. A user could bring up a new master clock on the network that, either by intention or mistake,
assumes the master role without providing better time.
Domain Time II optionally allows you to override the automatic selection of master clock by specifying the IP address(es) or CIDR mask(s)
of the master(s) to which you are willing to synchronize. When you override the automatic selection of master clock, Domain Time II only
pays attention to the IP addresses you specify; messages from other IP addresses are silently discarded.
If you are using the Telecom profile, you must enter the IP addresses of Telecom master(s) in this box. In Telecom mode, servers will be used in the order listed.
Default and Enterprise profile PTP nodes automatically choose a master according to the algorithm specified in the standard.
Note: In Default or Enterprise profile mode, specifying a list of machines for synchronization may result in no server being available because the other nodes
may elect a master that you have chosen to ignore. Use this option with caution.
As of v5.2.b.20190701, you may enter comments in the specified masters list. Comments are defined as text following a hashtag or semicolon.
(If the hashtag or semicolon is the first character, the entire line is considered a comment.) For example, you may use this syntax:
; These are our masters:
172.16.13.3 # main server
192.168.33.21 # backup server
For how to configure other available options, please see the IEEE 1588-2008/2019 specifications for explanations and recommended settings. Also, contact your vendor for device-specific recommendations/requirements for compatibility with their PTP products.
Configure Domain Time for Windows as a PTP Slave
