Domain Time II Configuration - Configure Domain Time for Linux (DTLinux) as a PTP Slave

Configure Domain Time for Linux (DTLinux) as a PTP Slave

Domain Time II Server
Version 5.2

Please review the Planning and Recommended Configurations pages before proceeding.

In order to use Domain Time for Linux (DTLinux) as a PTP Slave to an existing Master, you must make the following configuration choices to the dtlinux.conf file:

In the PTP Settings section of the .conf file, set the ptp:enabled setting to True.
IMPORTANT: Specify at least one reliable non-PTP server (either NTP or DT2) in the NTP and DT2 Time Sources section 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).

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.
In the Loop Variables section, set the loop:checkInterval to 60 seconds. Domain Time's PTP implementation is optimized for this setting. Do not set these values lower than every 30 seconds when using PTP. Although this setting does not control the PTP synchronization rate, it does affect sample collection and controls how often Domain Time synchronizes if falling back to DT2 or NTP, and also how often it records sync status in the text logs. Too short of a period may not allow PTP enough time to collect valid samples.
If your PTP Default or Enterprise profile Master is not on the same subnet as the Client, be sure the network:multicastTTL value in the Network Settings section of the .conf file is 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, this setting is irrelevant.
If you are going to be synchronizing using the Telecom profile, click the "Options" link and make the following additional selections:
1. Set the ptp:profile value to Telecom
2. Use the telecomMaster setting to specify the IP address(es) and domain 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, i.e.
3. If your telecom server is non-standard, you may need to adjust other telecom options to match your Master. Do not change these values unless your server requires them.
From a Linux commnd line, issue sudo systemctl reload dtlinux.service to have your changes recognized. If you used DTLinux control panel on Domain Time II Manager to edit the .conf file, then click either Apply or Save & Exit; changes will take effect immediately without any need to use systemctl (the same feature applies to any .conf changes you make using the DTLinux control panel). 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 verify this by examining the /var/log/domtime/dtlinux.log file. You can also check the activity of the PTP conversation from the Graphs & Statistics menu of the DTLinux control panel on Domain Time Manager.

Troubleshooting
The default PTP settings should be sufficient for DTLinux 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.

Be sure network communication for the PTP ports 319/UDP & 320/UDP is allowed bidirectionally through all switches and firewalls.

For multicast profiles, ensure that there is an IGMP (if using IPv4) or MLD (IPv6)-enabled router or switch 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.

Some IGMP routers need to have multicast group memberships refreshed occasionally or machines can be dropped from the group. If you encounter this behavior, you can use the network:igmpRefresh value to resend group membership info on a schedule.

To easily see which PTP masters are visible on your network, choose Open PTP Statistics & Masters from the Graphs and Statistics menu of the DTLinux control panel on Domain Time Manager. Click the PTP Masters link at the bottom of the stats display.
You may also issue the following command from a command-prompt:

dtcheck -ptpmasters
If you specified authorized Masters using the ptp:multicastMaster settings, be sure you haven't excluded your master in the list.
If your machine is multihomed, you may need to restrict DTLinux to use a specific network interface using the network:adapterName setting.
Use the ptp:profile value to specify the PTP profile being used by your Master if one isn't being autodetected.
Use the ptp:delayTransport value to specify the Delay Transport instead of "Auto."
Ensure the PTP ClockID/port 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 another machine has the same Clock Identity. The easist way to do this is to increment the ptp:portNumber value. You can also use the following command to reset the ClockID to a random value:
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. If things then start working, you need to verify that your authentication settings match your Master. Check your dtlinux.keys file 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.