Information and configuration instructions for using the Precision Time Protocol (IEEE 1588-v2) with Domain Time II.
A PTP network of hardware clocks on a well-regulated segment can usually synchronize to within a few tens or hundreds of nanoseconds.
Software implementations can theoretically achieve the same results, but are subject to limitations of the host operating system.
In particular, Windows, Linux, and BSD are not real-time operating systems, and the connecting networks are often congested or
have unpredictable or asymmetric performance characteristics. PTP implementations in these environments must estimate delays caused by
servicing interrupts, stack traversal, latencies introduced by expiring time slice quanta, and vagaries in the network itself.
By default, when an application tells the operating system to place a packet on the wire, it can know only when the packet left
the application, not when the packet finished traversing the operating system layers and was actually placed on the wire.
Likewise, incoming packets may suffer delays in the network driver or the operating system before being delivered to the application.
This degree of uncertainty produces “jitter,” or small variations in the measured time that are artifacts of the environment rather
than the protocol. In addition, any procedure can be preempted, leading to erroneous measurements of elapsed time.
Some operating systems, with assistance from the network driver, can provide a timestamp indicating when a particular packet
left or entered the system. Using this information, the application can determine how much extra time was spent handling the
packet between the application and the wire. The BSD-style socket options SO_TIMESTAMP or SO_TIMESTAMPNS are used to enable
this functionality on BSD or Linux. If the operating system and network driver support SO_TIMESTAMP or SO_TIMESTAMPNS, the
measurements of PTP can be significantly more precise than without such support.
Current Windows operating systems do not support SO_TIMESTAMP or SO_TIMESTAMPNS. However, as of Server 2019 and recent builds of Win10,
they do offer NDIS software timestamping measurement of internal network stack delays. Domain Time can use this function,
see KB2019.708 for more information.
The theoretical limit of precision for Domain Time II using any protocol is the hectonanosecond. A hectonanosecond is 100 nanoseconds,
or 1/10th of a microsecond. The real-world behavior of Domain Time II’s implementation of PTP achieves results as good or better than
any other supported protocol.
The presence of PTP on a network gives Domain Time II the opportunity to adjust the timing of the system up to 64 times per second.
This is not possible with conventional request-response time protocols because the overhead of making requests are prohibitive.
Domain Time II supports Precision Time Protocol version 2 (IEEE 1588-2008) which is used to determine the current time offset
and discipline the local clock on PTP slaves to a high degree of accuracy.
Domain Time II can be configured to run in slave-only PTP mode using the Default (multicast or hybrid), Enterprise, or (as of v5.2.b.20180606) the Telecom PTP profile
(see PTP Profiles below). This applies to both Domain Time II Client and Domain Time II Server.
Domain Time II Server allows you to let Domain Time II assume the master clock role using either the Default or Enterprise (Hybrid)
PTP Profiles. As of v5.2.b.20180801, Domain Time Server can also act as a Telecom master. This option should only be enabled if you have
no hardware-based PTP grandmaster, or if you need a software-based backup to your grandmaster. PTP is designed to work with
hardware-based clocks. Software-based clocks cannot offer the same degree of precision or accuracy as hardware-based clocks.
Using the Default or Enterprise profiles, Domain Time II attempts to automatically detect and synchronizes to the best master on the local segment.
When using the Telecom profile, you must must manually select the Telecom profile and configure a list of acceptable masters.
PTP has two delay-measurement mechanisms, End-to-End and Peer-to-Peer. Most master clocks can support either, but only one at a time.
Domain Time II auto-detects the delay mechanism and uses whichever one the master supports.
Domain Time is compatible with masters providing both one-step and two-step followups. When running as a Master, Domain Time Server
acts as a one-step clock.
PTP is a “chatty” protocol. The master clock sends announce, sync, and other messages on a regular basis, and slaves send
queries and responses of their own. The default sync frequency is one per second, but
most master clocks allow this number to be adjusted, and many administrators consider choosing a higher number.
Theoretically, the higher the rate of messages, the more accurately the slave can measure the master's information,
but this is primarily true only for hardware appliances. Domain Time II is heavily optimized to perform best at one sync packet
per second, so increasing the sync frequency can actually lead to worse performance.
A standard-compliant PTP node using the Default Profile operates using only multicast messages. This means that not only does every
node see the master’s messages, but every node sees every request made by every slave, and every reply. Domain Time II tries to
reduce this traffic by sending unicast delay requests (Hybrid Mode). The Enterprise Profile also uses unicast delay requests.
If the master clock supports multicast with unicast replies, Domain Time II will continue using only unicast for delay measurement
with that clock. If the master does not support unicast for delay requests, Domain Time II will fall back to using multicast.
Domain Time can also operate as a Telecom profile slave (as of v5.2.b.20180606) or master (as of v5.2.b.20180801). Telecom masters and slaves communicate solely over
When PTP is enabled on Domain Time II, it runs continuously in the background, exchanging messages with the master and collecting
statistics. You can see this activity using the Domain Time II logs and graphs from the links on the Obtain the Time property
page of the control panel applet.
PTPv1 is not supported. PTPv1 and PTPv2 are incompatible. A special appliance is required to separate v1 and v2 segments.
Domain Time II will not recognize or respond to PTPv1 messages.
Domain Time II does not support the experimental PTP authentication mechanisms described in Annex K of 1588-2008. A new type of
authentication is being developed for PTP v2.1, and Domain Time II will support that after it is finalized.
Optimum Environment for PTP
The hardware, software, and network environment is critical for PTP synchronization at the sub-millisecond level. This section will help
customers hoping to achieve sub-millisecond synchronization across your network of machines:
The best processors for time synchronization are Intel’s Core i7 line (or later) or Xeon E7 line (or later). Earlier chips are not as
stable or as precise as the newer models. The newer processors also have an invariant timestamp counter, which allows Domain Time II to
measure the passage of time accurately regardless of SpeedStep or other power-saving mechanisms. Issuing
DTCHECK /cpuid from the command-line will show you whether or not your processor supports an
Win8-Win10, or Server 2012-2019 are preferred and are more predictable than Vista, Windows 7, Windows 2008, or Windows 2008r2
for high-accuracy timing. The older XP/Server 2003 platform is also more stable than the problematic Vista/Win7/2008/2008r2 versions.
Domain Time Version
PTP is a loose and evolving standard. You should always use the most current version of Domain Time Server or Client to be sure you
are getting optimal performance and compatibility. Check the Changelog to
see details of the current version.
The lower the latency in your network switches or hubs, the better. Switches typically use store-and-forward technology, which means that
packets can be delayed even under ideal circumstances. During times of high traffic, the delay time can quickly soar to unacceptable levels. Even a small delay will affect timing, even though other applications may not even notice it. If you have managed switches, examine the statistics to determine if packets are being delayed. You may also set up a test environment and compare the synchronization accuracy in your test environment vs. your production environment. If the performance suffers in your production environment with identical equipment, suspect underpowered switches.
Some switches and routers have PTP-awareness (such those capable of operating as boundary clocks) which can intercept or interfere with PTP communications. Be sure you have updated
all of these to the latest firmware. Many implementations of these products have had significant bugs, such as preventing PTP management messages from being propagated correctly.
If your managed switch supports QoS, you should set it so that PTP traffic (to/from UDP ports 319 and 320) have the highest possibly priority.
Most user-mode applications do not affect timing significantly. However, programs that change the system clock resolution, or that
overtax the hardware, can degrade performance. If possible, avoid Java-based applications, Flash applications, or any program that
exercises the CPU excessively.
Miscellaneous Hardware and Drivers
Drivers for NICs, video, and disk subsystems can cause unpredictable delays in servicing interrupts. Windows timing relies on the
regularity and predictability of interrupts. If sub-millisecond timing is critical for your environment, use only the best and fastest
Some switches and routers have PTP-awareness (such those capable of operating as boundary clocks) which can intercept or interfere with PTP communications. Be sure you have updated
all of these to the latest firmware. Many implementations of these products have had significant bugs, such as preventing PTP management messages from being propagated correctly.
Any machine running either Hyper-V or VMWare will not perform as well as a stand-alone machine, although modern versions of Hyper-V (as of Server 2012) offer dramatically improved timing performance. This applies to both the host operating system and any guests, using any time synchronization protocol.
On older hardware or systems with high resource use/low memory, the extra overhead of handling the continual PTP network activity may actually result in more interrupt delays among guests, resulting in additional clock drift.
Use a hardware clock as your master, if possible
PTP works best with hardware-based grandmaster clocks. Although you may design a network using only software components, your accuracy will be somewhat diminished. We recommend careful planning to ensure you have hardware clocks available, and that their capacity is commensurate with your expected load. Your grandmaster manufacturer can help you plan your network.
To Configure Domain Time as a PTP Slave:
In order to use Domain Time 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 II 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).
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 recommend a setting of every 1 minute. 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.
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.
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.
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. Only one server will be used at a time. 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 a suitable Default or Enterprise profile 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. 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.
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 attached to the same subnet as your PTP Master and Slaves.
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):
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:
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 18.104.22.168) 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.
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.
The Precision Time Protocol IEEE1588-2008 (PTP) specification includes definition of several operating profiles.
A profile is simply a selection of settings and attributes optimized for different environments or purposes.
The idea behind profiles is that, as long as all nodes use the same profile, devices can interoperate with a minimum of user configuration.
The default profiles
IEEE 1588-2008 Annex J specifies two main default profiles for use with PTP. The profiles are identical except for the method of delay measurement specified.
Both of the default profiles use the IEEE1588-2008 defined "Best Master Clock" (BMC) algorithm to determine which node on the network is master.
It is not unusual for a network to consist of nodes using either of the default protocols.
Although the default profiles specify values for certain parameters, administrators have the ability to change some of them.
Many administrator-selectable values are distributed automatically, but several important ones are not. Domain Time automatically
queries the master using management messages to discover important variables when possible, minimizing manual configuration.
Other PTP devices or implementations may need to be manually configured for these items.
The Delay Request-Response Default PTP Profile (identifier code 00-1B-19-00-01-00) uses End-to-End (E2E) delay measurement.
Slaves send periodic delay requests via multicast to the entire network. A master overhearing the request sends
a multicast delay response packet with the slave request's sequence number and portIdentity. All nodes on the network hear each
request and each response, even though delay requests are only answered by masters, and a particular delay response is only
meaningful to the slave listening for that particular packet. The delay request frequency is normally controlled by the
master when using E2E. The required interval is sent as part of the master’s regular packets. Domain Time II allows you to override
this automatic request frequency and specify a fixed interval.
The Peer-to-Peer Default PTP Profile (identifier code 00-1B-19-00-02-00) uses Peer-to-Peer (P2P) for delay measurements.
The operation is very similar to E2E, but is primarily used by Boundary Clocks, or between multiple appliance-type grandmasters,
rather than by individual nodes. The P2P request packet is larger, and the response may be either one-step or two-step.
Two-step responses are used by masters who can measure the exact departure time of the first reply, but cannot dynamically
rewrite the contents of the first reply to include the correct time. The second reply contains a more precise timestamp.
P2P uses the master’s announce frequency times as an implementation-dependent multiplier to derive the delay request frequency.
Domain Time II allows you to override this automatic request frequency and specify a fixed interval.
P2P suffers the same excessive bandwidth issue as E2E, in that all requests and responses are sent to the entire network via multicast.
Since using multicast for all PTP traffic is an inefficient use of network resources, methods have been introduced to
reduce the amount of multicast traffic, primarily by using directed unicast packets for the delay measurement portion of
the PTP conversation between masters and slaves.
Hybrid Mode is not defined by IEEE1588-2008, but it is in common use. It does not have an identifier code of its own;
rather it operates using either E2E or P2P with one important difference: Delay requests are sent directly to the master
using unicast. Masters that support hybrid mode will send the reply by unicast directly back to the requesting slave.
This allows messages that need to be seen by the entire network (a master's Announces and Syncs) to continue being multicast,
but limits delay measurement exchanges to only the nodes that need to see them. Other nodes do not need to process and discard
inapplicable delay measurement requests or replies. Domain Time, PTPd, and most other implementations of IEEE1588-2008,
support hybrid mode. Most grandmaster appliances also support it. Appliances that do not support hybrid mode may respond to
unicast requests with multicast responses, or may not respond at all (the behavior is manufacturer-defined).
Domain Time automatically detects both which profile to use and whether or not hybrid mode is supported by the master.
Unicast negotiation is described in Table 34 of the IEEE1588-2008 standard (REQUEST_UNICAST_TRANSMISSION).
Negotiated unicast works somewhat like DHCP, in that leases are requested, granted or denied, have expiry times, and
must be renewed. This is primarily useful in networks that do not allow multicast, such as older telecommunication networks.
Domain Time supports unicast negotiation as a slave (as of v5.2.b.20180606) or master (as of v5.2.b.20180801) using the Telecom Profile.
IEEE 1588-2008 v2.0 specifies a "domain" to be a number in the range of 0-127 (default 0), that logically separates multiple timing
networks on the same wire. Version 2.1 allows domain numbers to extend to 239. Each node is required to have an operating domain number, and to ignore messages originating from
or addressed to a different domain number.
Two equal grandmasters in the same domain will not both send Announce and Sync messages. Using the BMC algorithm, they will decide which
is primary and which is secondary. The secondary grandmaster will enter passive mode, waiting for the primary to go offline or suffer
a clock degradation, at which point the roles will switch. This mechanism works as expected as long as the grandmasters use the same
Multiple grandmasters visible on the same wire may all act as primaries as long as they each use a different domain
number. In this way, networks can be logically separated even if not physically segmented.
Slaves, too, have an operating domain, and IEEE1588-2008 requires them to exercise the BMC algorithm only among masters advertising
in the same domain. The Enterprise Profile (see below) provides for slaves to follow masters in more than
one domain, although the mechanism and selection criteria are implementation-dependent. As of version 5.2.b.20161215, Domain
Time supports the dynamic domain concept, whether or not the Enterprise Profile is specified. When dynamic domain is enabled,
Domain Time slaves will choose the best master from among all visible masters in domains 0 through 127 (or through 239 if using v2.1),
and change their operating domain to match the domain of the selected master.
The "All Domains" Domain Number
Domain numbers are conveyed in an unsigned 8-bit value. Ordinary v2.0 clocks are restricted to domains 0-127. Values from 128-239 are
available for version 2.1 use. Other values are reserved.
IEEE1588-2008 supports special values for clockIdentities and portNumbers that act as wildcards for management messages. A clockIdentity
of all 1's is addressed to "all clocks," and a portNumber of all 1's is addressed to "all ports." Therefore a portIdentity of all 1's
means "all ports of all clocks" but is limited to nodes using the same domain.
Oddly, IEEE1588-2008 does not include a wildcard "all domains" value. An 8-bit value of all 1's is 255 (0xFF), and is reserved by the
standard, so is the perfect candidate for a domain wildcard value. Domain Time will respond to management messages addressed to
domain 255. The reply will contain the node's current operating domain. In theory, a management station could send a single multicast
addressed to all clocks, all ports, all domains, and, by collecting the responses, discover the identities of each node, including
all of the logical domains in use.
Because the "all domains" domain wildcard is not in PTPv2.0 or v2.1, Domain Time does not place messages
addressed to the wildcard domain on the wire, but will respond correctly to management messages addressed this way.
Various additional profiles have been introduced to address specialized needs or industry requirements.
The Enterprise Profile (identifier code 00-00-5E-00-01-00,
see draft 09 et sequelae)
is an emerging standard that is already widely deployed. It is a specialized version of the default End-to-End Profile, and is
interoperable with the default End-to-End Profile. It provides potentially tighter synchronization, allows for slaves to follow
masters in multiple domains, and eliminates the need to query the masters for network variables.
Domain Time, in auto-detect mode, will use the values provided by the master, regardless of whether the master is using the
End-to-End Default Profile or the Enterprise Profile. As of version 5.2.b.20170101, you may force Domain Time to use the
When using the Enterprise Profile as a slave, Domain Time will not query the master; it always uses the
values specified by the profile, and always uses hybrid mode. When using the Enterprise Profile as a master, Domain Time uses
the values specified by the profile, will respond to multicast queries with multicast responses, and will respond to unicast
queries with unicast responses.
Note that although the Enterprise Profile's basic goal is largely designed around codification of hybrid mode, it also sets
several values intended to be fixed. As with the default profiles, manufacturers can vary some of these values. In particular,
a master may send Sync messages more often than once per second, and it may provide, when queried, a different delay measurement
interval for slaves to use.
— This profile is a codification of hybrid mode, with fixed values for packet intervals
— Uses a fixed announce multiplier of 3 through the network
— Requires masters to use a fixed announce interval of 1
— Requires masters to use a fixed sync interval of 1
— Requires masters to use multicast for Announce and Sync messages
— Requires masters to respond to unicast delay requests with unicast delay responses
— Slaves use a fixed delay measurement interval of 1
— Slaves are forbidden from attempting unicast negotiation
— Slaves are required to use E2E instead of P2P for delay measurement
— Slaves are allowed to choose from masters in multiple domains
— Slaves are encouraged to use unicast for delay requests
— Nodes are not forbidden from using multicast for management messages
— Masters are not forbidden from responding to multicast messages via multicast
The Telecom Profile (identifier code 00-19-A7-00-01-00) is not one of the default profiles and is not compatible with them.
Each slave node must be configured with the IP address and domain number of the master(s) it is allowed to use. The slave then obtains
separate leases for Announces, Syncs, and E2E delay measurements by exchanging unicast messages with the master(s). The Telecom Profile
uses a custom BMC algorithm, as defined by ITU-T G.8265.1, using the master's clockClass, the master's priority 2 value, and finally
the local priority. Local priority is based on the order in which you provision the list of masters. The Telecom Profile requires that
a given node is either always a slave or always a master; this is why Domain Time, when configured to use the Telecom Profile as a slave,
can never assume the master role. Domain Time supports unicast negotiation as a slave (as of v5.2.b.20180606) or master (as of v5.2.b.20180801).
Since you must provision a Telecom Profile slave with the master's IP and domain number, the Dynamic Domain checkbox will be grayed-out.
Domain Time can follow up to sixteen Telecom masters in any combination of domains.
The 802.1AS Profile (identifier code 00-80-C2-00-01-00) is aimed primarily at the audio-video industry.
This is a specialized version of the default Peer-to-Peer Profile using multicast for all messages, and different requirements for
certain types of message contents. Its primary goal is to provide reliable timestamps across multiple nodes used for streaming
source material. It is not, generally, interoperable with the default Peer-to-Peer Profile, and there are several mutually-incompatible
versions in common use. Domain Time can usually slave successfully to an 802.1AS master, but compatibility must be determined on a
trial-and-error basis due to the conflicting definitions.
The SMPTE ST-2059-2 Professional Broadcast Environment Profile (identifier code 68-97-E8-00-01-00) for video synchronization.
The profile is similar to the Default Profile, but requires different scheduling of Announce and Sync messages, as well as using Domain 127.
Domain Time should be able to synchronize as a slave using this profile.
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.
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.
The default operation of Domain Time II is to detect the delay mechanism used by the master clock. The options are:
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
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:
Unicast (hybrid mode)
Multicast (standard mode)
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.
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 ablity 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. 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.
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 specification for explanations and recommended settings. Also, contact your vendor for device-specific recommendations/requirements for compatibility with their PTP products.