Rpi (802.1AS SW timestamping mode) + LS1021ATSN (802.1 HW timestamping mode)
Opened this issue · 7 comments
Currently I'm using RPI (slave) and LS1021ATSN (master) for clock synchronization.
Since Rpi does not support HW timestamping, gPTP.cfg is modified to use "software" in timestamping parameter. But there is no announce message out from Rpi and master tx timeout in both LS1021ATSN switch and RPI and act as grandmaster role independently.
Does the architecture will work?
What do you mean "master tx timeout"? You mean you run ptp4l with "-l 7" for debugging logs and you see messages like this?
ptp4l[219.741]: port 1: master sync timeout
ptp4l[219.741]: port 1: master tx announce timeout
ptp4l[220.256]: port 1: delay timeout
ptp4l[220.741]: port 1: master sync timeout
Those are normal, they mean that event timers expire in the ptp4l program for various actions, like send a Sync message, an Announce message etc.
Does the architecture will work?
Depends what you're looking for. The performance will not be great (the sync offset will probably be stable to a degree of +/- 10 ms or so).
The reason why they won't sync is probably due to the neighborPropDelayThresh value in gPTP.cfg. Try commenting that out.
I understood the master sync timeout is normal.
Here is LS1021ATSN master and RPI slave config.
[global]
gmCapable 1
priority1 248
priority2 248
logAnnounceInterval 0
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
network_transport L2
delay_mechanism P2P
Thanks. I got it working.
I have a questions in this case, from the ptp stack what I understood is, if the neighborPropDelay is greater than neighborPropDelayThresh then the asCapable is set to false for that corresponding ports. Do we need to calculate the neighborPropDelay based on the hops?
Do we need to calculate the neighborPropDelay based on the hops?
The value of 800 ns is pretty much arbitrary, I couldn't find any reference in any standard for why linuxptp chooses this number. It is only there to ensure that there aren't PTP-unaware switches in the network, because two MACs and a switching fabric would increase the path delay just enough to exceed the threshold, and also the path delay jitter (this will hurt the synchronization and is the reason why 802.1AS denies PTP-unaware devices).
However, sometimes even some directly-connected PHYs with hardware MAC-level timestamping exceed a path delay of 800 ns. So that is why I suggested to just delete the neighborPropDelayThresh value. With software timestamping I expect it is pretty much a moot check and cannot be used to usefully detect any invalid configuration of the network.
Understood. One interesting finding;
RS_SLAVE state to SLAVE (MASTER_CLOCK_SELECTED) state takes more than 4 minutes. Do you think adjusting step_threshold parameters will help me to switch the state faster?
No, I don't think it will. Hardware timestamping will, on the other hand.
I don't think even the latest BCM2711 in the Raspberry Pi 4 with its bcmgenet driver offers hardware timestamping. Other similar SBCs, however, will, like the Beaglebone Black (TI AM335x), Wandboard (NXP i.MX), etc etc.
Okay. Thanks for your support. I will look into the optimization and improvement by tuning ptp4l parameters to get some better numbers and keep you posted. Cheers.