Help needed - Want to configure linux computer as Boundary Clock

[VimalMollyn]

Hi!

I have a desktop computer running Ubuntu 18.04, containing 5 ethernet ports (with separate NICs). I'm having a hard time setting up the ptp4l and phc2sys services.

I want to sync data from multiple ethernet capable sensors using PTP. To do this, I want to configure my desktop computer as a boundary clock (synced with a grandmaster clock, which syncs using GPS). From my understanding, I have to setup one of the 5 ethernet ports as a slaveOnly (to the grandmaster clock) and the rest of the ports as masters to their respective sensors. The sensors have PTP timestamping support. Does this make sense?

Here's what I tried: I edited the ptp4l.conf file to include the following lines:

[global]
# defaults
.
.
.
# port to configure as a slaveOnly
[eth0]
slaveOnly          1

[eth1]
[eth2]
[eth3]
[eth4]

On restarting the ptp4l service, I get an error saying "unknown option slaveOnly" in eth0 section.

Am I setting the configuration correctly? How could I achieve the required functionality? This is my first time setting up PTP hardware time sync.

Thanks! Vimal

[janruh]

Hi Vimal,

try running ptp4l as follows: sudo ./ptp4l -f <config file> -i eth0 -i eth1 -i eth2 -i eth3 -i eth4 -m -H -s

With -H you tell Linux PTP to use hardware timestamping -s tells it to run in slave only mode. Why your slaveOnly configuration is not working I cannot tell with the information given however you have to consider which profile of PTP you are using. Checkout the existing configuration file in the configs directory.

[VimalMollyn]

Hey @janruh, Thanks for helping out. I tried running the command you suggested, still getting the same error - unknown option clientOnly at line 118 in eth0 section.

Also, I'm confused how the command you suggested will ensure that eth0 is slaveOnly, and the rest are masters? Furthermore, what do you mean by the PTP profile? And how do I set that?

[janruh]

Hey,

first of all it would be good to see your complete configuration file. LinuxPTP supports a number of different configurations that are standardized by IEEE, e.g., IEEE 1588-2008 or IEEE 802.1AS. If you mix configuration options of different profiles or standards they might not be compatible and you run into problems.

Next, usually LinuxPTP uses the best master clock algorithm (BMCA) to pick the grandmaster clock (GM). If you configure all your nodes except your intended GM to operate as slaves only or prevent them from being picked as grandmaster clock by the BMCA algorithm, e.g. by setting specific configurations, your node with GPS will be picked as GM. As a result eth0 (which is connected to the NIC of the VM) will operate in slave mode which puts eth1 - eth4 into master mode and accordingly your sensors again in slave mode.

I would recommend you use the configs/gPTP.cfg configuration. In there you can set the gmCapable option and further you can also set the priority1 and priority2 option that are being used by the BMCA algorithm to determine the GM (lower means being favored for GM role). This way you can force your intended node to be picked as GM.

Besides, your sensors execute PTP im some way? You should also figure out which standard they implement.

[VimalMollyn]

Thanks for the detailed reply. The sensors I use support IEEE 1588 PTP (I'm not sure which version of that, need to look that up). Here's the complete config file that I was using.

[global]
#
# Default Data Set
#
twoStepFlag     1
slaveOnly       0
socket_priority     0
priority1       128
priority2       128
domainNumber        0
#utc_offset     37
clockClass      248
clockAccuracy       0xFE
offsetScaledLogVariance 0xFFFF
free_running        0
freq_est_interval   1
dscp_event      0
dscp_general        0
dataset_comparison  ieee1588
G.8275.defaultDS.localPriority  128
maxStepsRemoved     255
#
# Port Data Set
#
logAnnounceInterval 1
logSyncInterval     0
operLogSyncInterval 0
logMinDelayReqInterval  0
logMinPdelayReqInterval 0
operLogPdelayReqInterval 0
announceReceiptTimeout  3
syncReceiptTimeout  0
delayAsymmetry      0
fault_reset_interval    4
neighborPropDelayThresh 20000000
masterOnly      0
G.8275.portDS.localPriority 128
asCapable               auto
BMCA                    ptp
inhibit_announce        0
inhibit_delay_req       0
ignore_source_id        0
#
# Run time options
#
assume_two_step     0
logging_level       6
path_trace_enabled  0
follow_up_info      0
hybrid_e2e      0
inhibit_multicast_service   0
net_sync_monitor    0
tc_spanning_tree    0
tx_timestamp_timeout    1
unicast_listen      0
unicast_master_table    0
unicast_req_duration    3600
use_syslog      1
verbose         0
summary_interval    0
kernel_leap     1
check_fup_sync      0
#
# Servo Options
#
pi_proportional_const   0.0
pi_integral_const   0.0
pi_proportional_scale   0.0
pi_proportional_exponent    -0.3
pi_proportional_norm_max    0.7
pi_integral_scale   0.0
pi_integral_exponent    0.4
pi_integral_norm_max    0.3
step_threshold      0.0
first_step_threshold    0.00002
max_frequency       900000000
clock_servo     pi
sanity_freq_limit   200000000
ntpshm_segment      0
msg_interval_request    0
servo_num_offset_values 10
servo_offset_threshold  0
write_phase_mode    0
#
# Transport options
#
transportSpecific   0x0
ptp_dst_mac     01:1B:19:00:00:00
p2p_dst_mac     01:80:C2:00:00:0E
udp_ttl         1
udp6_scope      0x0E
uds_address     /var/run/ptp4l
#
# Default interface options
#
clock_type      OC
network_transport   UDPv4
delay_mechanism     E2E
time_stamping       hardware
tsproc_mode     filter
delay_filter        moving_median
delay_filter_length 10
egressLatency       0
ingressLatency      0
boundary_clock_jbod 0
#
# Clock description
#
productDescription  ;;
revisionData        ;;
manufacturerIdentity    00:00:00
userDescription     ;
timeSource      0xA0

[enp4s0]
slaveOnly       1

This is just the defult.cfg file with a few extra lines at the bottom.

I shall try modifying the gPTP.cfg file and get back to you. Thanks for all your help!

[janruh]

Hi,

I think this default config is not actually functional it just shows all the possible options (I might be corrected here though). Try to figure out what standard your sensors actually support then create a configuration file where you only tweak those parameters that are required by the standard your sensors use. I am not sure if the gPTP.cfg will be compatible with your sensors.

[VimalMollyn]

Hey,

Thanks so much for your help. I realised it was an issue from my end - I had not set the grandmaster clock domain number :)

[VimalMollyn]

Hey,

I'm currently able to set up the computer as a boundary clock using the following config file (currently only connecting a sensor to eth1):

[global]

# Default Data Set
clientOnly                     1
domainNumber            4

# Run time options
tx_timestamp_timeout    3
BMCA                             noop
boundary_clock_jbod     1

# [eth0]
# 
# # Default interface options
# # clock_type               BC
time_stamping               hardware

[eth0]
serverOnly              0

[eth1]
serverOnly              1

I then run sudo ./ptp4l -f /config_file_loc.conf -m This runs for a while and then shows the following warnings:

updating UTC offset to 37
ptp4l[380.269]: port 2 (eth1): master state recommended in slave only mode
ptp4l[380.269]: port 2 (eth1): defaultDS.priority1 probably misconfigured

1. What does this mean? And what's a possible fix?

Another warning that shows up frequently:

timed out while polling for tx timestamp
ptp4l[354.737]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[354.737]: port 1 (eth0): send delay request failed
ptp4l[354.737]: port 1 (eth0): SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[370.739]: port 1 (eth0): FAULTY to SLAVE on INIT_COMPLETE
ptp4l[370.928]: port 1 (eth0): minimum delay request interval 2^-7

2. I tried alleviating this by increasing the tx_timestamp_timeout from 1 to 3, but it hasn't helped out. What could be a possible fix here?

3. When I connect the ptp enabled sensor to eth1, while the ptp4l service is not running, it shows timestamps starting from 0,1,2,... (basically time since boot. for that sensor). The moment I start the ptp4l service, the timestamp gets adjusted to the system time (~1615367543) . However, on further testing, I found out that this timestamp was with reference to the clock of the NIC that the sensor was connected to (i.e, NIC of eth1) and this clock only gets set on boot up. So any further syncs that happen between the GrandMaster and eth0 (slave port) do not get reflected on the other NICs, until a reboot. Is there a way to sync the NICs with the clock of the eth0 (slave port, synced with GrandMaster)? Currently I use phc2sys to sync the time from eth0 to the system time, using the following command:

sudo phc2sys -s eth0 -r -n 4 -w

Should I be doing something else instead, to sync up the clocks on the NICs?

[janruh]

Hi,

1. This probably has to do with your somewhat incomplete configuration file. Is any PTP device connected to eth1 or is it not in use at all?
2. Try increasing the tx_timestamp_timeout significantly. I think the unit here is ms to maybe try setting it to 100ms and see if the occasional timeout persists.
3. I think this is connected to 1. In your configuration your device is not really acting as bridge since it seems like eth1 is not being synchronized. Try removing the serverOnly option (what does it even do? I've never used it). Then try to run linuxptp as follows manually adding the interfaces that shall be synchronized: sudo ./ptp4l -f config_file_loc.conf -i eth0 -i eth1 -s -H -m

[VimalMollyn]

Hi,

I have a device connected to eth1. The goal with the config file is similar to your command. I think it works now, with the following command from phc2sys: sudo phc2sys -a -r -n 4 -m

Basically, this seems to wait for ptp4l to specify which NIC is the master and syncs the other NICs accordingly. The key flag here was -n which is for the domain Number of the grandmaster clock. Hope this helps others!

I am still iterating on problems 1 and 2. I'm going to try increasing the tx_timestamp_timeout to 100ms like you said. Will keep this thread posted. But something to note is that even with the timeout, the service seems to restart and work just fine (I kept it running for 24 hrs and the NICs were still in sync) - not sure how important this warning is.