search

nxp-archive / openil_linuxptp

PTP IEEE 1588 stack for Linux
GNU General Public License v2.0
136 stars 60 forks source link

Is it possible to achieve time synchronization through a non-TSN hub? #45

Open jack04060201 opened 1 year ago

jack04060201 commented 1 year ago

Hello, I'm trying to connect two devices to ls1021a-tsn, through a hub for time synchronization. help drawio It's clear that I have failed as the clocks are not synchronized. I suspect that this might be because PTP cannot synchronize two devices simultaneously on a single port.

help drawio (1) So, I attempted to remove one of the computers. If it's possible to synchronize them through the hub, maybe I can use two different MAC addresses to achieve synchronization. However, that also failed. Why can't I achieve one-to-one synchronization in the scenario where a hub is involved? Because I'm receiving PTP packets from the avb-bridge on the PC as usual.

vladimiroltean commented 1 year ago

What linuxptp configuration file are you using?

jack04060201 commented 1 year ago

What linuxptp configuration file are you using?

Hello, this is my PTP configuration.

When using the command, avb-bridge is accompanied by the -m option, while the PC is accompanied by the -s option.

Thank you for your response.

[global] gmCapable 1 priority1 248 priority2 248 socket_priority 7 logAnnounceInterval 0 logSyncInterval -3 syncReceiptTimeout 3 neighborPropDelayThresh 1000 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 tx_timestamp_timeout 200 step_threshold 0.00002

vladimiroltean commented 1 year ago

Increase neighborPropDelayThresh to a value higher than 1000 (ns == 1 us). A hub will increase the link delay which will cause the gPTP protocol to detect that the PTP link partners aren't directly connected and to fail. IOW, it fails by design, but you can still hack it if you want to. Nothing to do with having different MAC addresses.

jack04060201 commented 1 year ago

Increase neighborPropDelayThresh to a value higher than 1000 (ns == 1 us). A hub will increase the link delay which will cause the gPTP protocol to detect that the PTP link partners aren't directly connected and to fail. IOW, it fails by design, but you can still hack it if you want to. Nothing to do with having different MAC addresses.

Hello, I successfully synchronized one of the PCs by making modifications. Thank you for your assistance.

However, I need to synchronize both computers simultaneously. When I mentioned different MAC addresses, I was referring to enabling two different PTP programs and using different ptp_dst_mac to synchronize the same computer. Is it possible to use ptp4l to synchronize both of them in the original scenario?

vladimiroltean commented 1 year ago

01:80:C2:00:00:0E is a multicast MAC address. Use your favorite search engine to find out what that means. You don't need separate ptp4l processes on the GM for multiple slaves.

jack04060201 commented 1 year ago

01:80:C2:00:00:0E is a multicast MAC address. Use your favorite search engine to find out what that means. You don't need separate ptp4l processes on the GM for multiple slaves.

Yes, I understand that ptp4l uses multicast for synchronization. However, even though I used the -s option on both PCs, I still encountered multiple peer responses and rogue peer delays. That's why I suspect that it may not work properly with multiple devices. I am currently researching this issue.

vladimiroltean commented 1 year ago

Multiple peer responses are expected, since there are truly multiple PTP peers on the same Ethernet segment, thanks to the hub. Use "delay_mechanism E2E" instead of P2P.

jack04060201 commented 1 year ago

When I use E2E, I don't receive any packets from the bridge, and all endpoints are in the "selected local clock as best master" state.

vladimiroltean commented 1 year ago

Yes, I'm afraid you'll have to remove the LS1021A-TSN switch from the path, or use PTP over IP on the endpoints to bypass its PTP packet processing. You can't combine technologies quite so freely.

jack04060201 commented 1 year ago

Yes, I'm afraid you'll have to remove the LS1021A-TSN switch from the path, or use PTP over IP on the endpoints to bypass its PTP packet processing. You can't combine technologies quite so freely.

Unfortunately, ls1021a-tsn is the backbone of my network and cannot be removed. So, I am trying to bypass this limitation by using two PTP programs. Strangely, even though I changed the ptp_dst_mac setting on one of the PCs, it still seems to be affected by packets with the destination MAC address 01:80:c2:00:00:0e, resulting in multiple peer responses. Do you think it is possible to achieve this, or is it constrained by the underlying program?

vladimiroltean commented 1 year ago

It's not because of the MAC address, it's because in peer delay mode, a port doesn't expect to have more than one peer. The presence of those extra peers on the common Ethernet segment is, as mentioned repeatedly, caused by the hub which is PTP unaware. Replacing that device with a PTP aware switch would solve the problem by speaking peer delay individually with all endpoint devices, as well as with the central LS1021A-TSN.

jack04060201 commented 1 year ago

It's not because of the MAC address, it's because in peer delay mode, a port doesn't expect to have more than one peer. The presence of those extra peers on the common Ethernet segment is, as mentioned repeatedly, caused by the hub which is PTP unaware. Replacing that device with a PTP aware switch would solve the problem by speaking peer delay individually with all endpoint devices, as well as with the central LS1021A-TSN.

I don't have that many devices at hand, so I will try using one of the PCs on the hub as a master to synchronize with the other PC using an additional port. It may not be the good solution, but it could serve as an alternative.

Anyway, thank you for your help and suggestions. they have been very helpful to me.

vladimiroltean commented 1 year ago

When I use E2E, I don't receive any packets from the bridge, and all endpoints are in the "selected local clock as best master" state.

If you configure the LS1021A-TSN as an E2E boundary clock, your endpoints should be able to synchronize with it. I don't see why that shouldn't work. I think you left the LS1021A-TSN in P2P and only switched the endpoints to E2E.

jack04060201 commented 1 year ago

When I use E2E, I don't receive any packets from the bridge, and all endpoints are in the "selected local clock as best master" state.

If you configure the LS1021A-TSN as an E2E boundary clock, your endpoints should be able to synchronize with it. I don't see why that shouldn't work. I think you left the LS1021A-TSN in P2P and only switched the endpoints to E2E.

I did have concerns about this issue, so I tried both configurations. When using P2P mode with E2E endpoints, I encountered Pdelay_req warnings. However, when using E2E mode, nothing happened, and there were no packets captured in Wireshark.

vladimiroltean commented 1 year ago

On which station did you run wireshark? If you run "tcpdump -i swpN -e -n -Q in" (replace N with the port number) on the LS1021A-TSN, is there nothing there?

jack04060201 commented 1 year ago

Wireshark on the PC, whether directly connected or using a hub, did not capture any packets. TCPdump on LS1021a-tsn also did not detect any 0x88f7 packets. The PTP4l on LS1021a-tsn is built from OpenIL.

vladimiroltean commented 1 year ago

If no PTP packets are seen on SJA1105 ports, are they dropped or are they not sent? If you run "ethtool -S swpN | grep -v ': 0'" multiple times in succession on the LS1021A-TSN board while PTP is supposed to be received, which counters increment?

vladimiroltean commented 1 year ago

The PTP4l on LS1021a-tsn is built from OpenIL

Just ptp4l, or the entire system? Which OS and kernel is the LS1021A-TSN running?

jack04060201 commented 1 year ago

If no PTP packets are seen on SJA1105 ports, are they dropped or are they not sent? If you run "ethtool -S swpN | grep -v ': 0'" multiple times in succession on the LS1021A-TSN board while PTP is supposed to be received, which counters increment?

The values of rx_packet, rx_bytes, n_rxfrm, n_rxbyte, n_txfrm, and n_txbyte have increased.

jack04060201 commented 1 year ago

The PTP4l on LS1021a-tsn is built from OpenIL

Just ptp4l, or the entire system? Which OS and kernel is the LS1021A-TSN running?

entire system, and the kernel is linux 5.4.3-rt1 #SMP PREEMPT_RT armv71

jagmeethanspal commented 1 year ago

Actually the thing you are trying to achieve (sync multiple .1AS end-hosts through a Hub) from a port of a device acting as gPTP clock-source / master, is what the gPTP .1AS is meant to avoid (by design), as Vladimir mentioned. The profile uses P2P to ensure each device in the clock-tree all the way from the GM to the end-client is time-aware (i.e. running as gPTP bridge).

PTP can be used to synchronise multiple-clients on the same port, but that would be through a different profile / delay_mechanism (E2E).

~ Jagmeet

On 07-Jul-2023, at 6:47 PM, jack04060201 @.***> wrote:

Increase neighborPropDelayThresh to a value higher than 1000 (ns == 1 us). A hub will increase the link delay which will cause the gPTP protocol to detect that the PTP link partners aren't directly connected and to fail. IOW, it fails by design, but you can still hack it if you want to. Nothing to do with having different MAC addresses.

Hello, I successfully synchronized one of the PCs by making modifications. Thank you for your assistance.

However, I need to synchronize both computers simultaneously. When I mentioned different MAC addresses, I was referring to enabling two different PTP programs and using different ptp_dst_mac to synchronize the same computer. Is it possible to use ptp4l to synchronize both of them in the original scenario?

— Reply to this email directly, view it on GitHub https://github.com/nxp-archive/openil_linuxptp/issues/45#issuecomment-1625403439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIYKMIWOIKTR2GOOTICQDDXPAD7JANCNFSM6AAAAAA2BX22JM. You are receiving this because you are subscribed to this thread.

jack04060201 commented 1 year ago

Actually the thing you are trying to achieve (sync multiple .1AS end-hosts through a Hub) from a port of a device acting as gPTP clock-source / master, is what the gPTP .1AS is meant to avoid (by design), as Vladimir mentioned. The profile uses P2P to ensure each device in the clock-tree all the way from the GM to the end-client is time-aware (i.e. running as gPTP bridge). PTP can be used to synchronise multiple-clients on the same port, but that would be through a different profile / delay_mechanism (E2E). ~ Jagmeet

Yes, this is just an attempt I chose as a temporary substitute considering the shortage of devices.

vladimiroltean commented 1 year ago

If no PTP packets are seen on SJA1105 ports, are they dropped or are they not sent? If you run "ethtool -S swpN | grep -v ': 0'" multiple times in succession on the LS1021A-TSN board while PTP is supposed to be received, which counters increment?

The values of rx_packet, rx_bytes, n_rxfrm, n_rxbyte, n_txfrm, and n_txbyte have increased.

So if PTP packets are received by the MAC but not by software, maybe DSA cannot decode their source port. What MAC DA do these PTP packets have? If it's not 01-80-c2-xx-xx-xx or 01-1b-19-xx-xx-xx, you can't timestamp them with SJA1105.

jack04060201 commented 1 year ago

If no PTP packets are seen on SJA1105 ports, are they dropped or are they not sent? If you run "ethtool -S swpN | grep -v ': 0'" multiple times in succession on the LS1021A-TSN board while PTP is supposed to be received, which counters increment?

The values of rx_packet, rx_bytes, n_rxfrm, n_rxbyte, n_txfrm, and n_txbyte have increased.

So if PTP packets are received by the MAC but not by software, maybe DSA cannot decode their source port. What MAC DA do these PTP packets have? If it's not 01-80-c2-xx-xx-xx or 01-1b-19-xx-xx-xx, you can't timestamp them with SJA1105.

The MAC address remains as 01-80-c2-00-00-00-0e, with the only difference from the initial configuration being the addition of neighborPropDelayThresh and the change in delay_mechanism to E2E.