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
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
Set the ptp:profile value to
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.
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.
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:
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:
sudo dtlinux -resetClockId
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
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.