how to config trasprarent clock in ptp4l

[hi123ping]

i want to test transpent clock use ptp4l, how wo config a device to be transparent clock

[vladimiroltean]

This is not the official linuxptp support site, please send your email to linuxptp-users@lists.sourceforge.net. Also, take a look at the configs/E2E-TC.cfg and configs/P2P-TC.cfg files, you can specify the path to them using "ptp4l -f <*.cfg>". Also see "clock_type" in "man ptp4l".

[hi123ping]

i mean a transprent clock have a ingress timestamp and a egress port modiyf a cf field in eht event packt, so how to config these two port in ptp4l. like ptp4l -E -i eth0 -i eth1 -f /..../E2T_TC.cfg ?

[vladimiroltean]

Yes, that's what a transparent clock does, it forwards PTP messages while updating the correctionField.

[hi123ping]

thank you for quicly answer. is that true ingress port always modify cf field by minus ingress timestamp and the egress port always modify cf by added egress timestamp?

[vladimiroltean]

Please check the way in which event messages are forwarded, in tc_fwd_event() from tc.c, and how the "residence" variable is calculated, passed to tc_complete() and used to update, for example, fup->header.correction (in the case of a follow-up message).

[hi123ping]

another question, so far 802.1as relay instatnce has not been supported in ptp4l, right? what dfficulty in support relay instance?

[vladimiroltean]

802.1AS bridge mode is supported by the OpenIL fork of linuxptp that you are commenting on. It is not supported by the upstream linuxptp. Check the git log of this tree, the 802.1AS bridge patches are on top.

[hi123ping]

ok , i see README features not updated. it tells only supported 802.1as role of end station

[vladimiroltean]

"Add IEEE 802.1AS-2011 time-aware bridge support" https://github.com/openil/linuxptp/commit/1486660e959f728e3a032cb832ee8b8ea9755ef3

[hi123ping]

can i set only one port in transparent clock? can i treat device A and device B as a logical big transprent clock? that means when packet path is (eth0) A (eth1)------>(sw0) B (sw1) , i need port eth1 in A and sw0 in B are dummy, they do not modify cf field. eth0 has the ingress timestamp and sw1 has egress timestamp and these two stamps make the residence time.

[vladimiroltean]

Devices A and B are different boards? No. Why do you need this? The TC A will update the correctionField not only with its residence time, but also with the estimated peer delay on its port towards TC B (eth1).

[vladimiroltean]

What you want isn't possible anyway. It would introduce the requirement that boards A and B are synchronized to each other, otherwise the delta between TX timestamp @ sw1 and RX timestamp @ eth0 makes no sense. Transparent clocks don't need to be synchronized to the GM.

[hi123ping]

yes , A and B are two boards。A and B has same timebase by other way. sometimes there are devices which does not support 1588 or 802.1as. that is A ------->clouds---->B. We need update residence between A and B. if ptp4l update cf field on ingress and egress port independenty, then it can handle this case.

[hi123ping]

the ptp4l current version can only handle residence between two ports on one board? only egress port modify cf by plus (egress timestamp - ingress timestamp) to cf ? actally , can we do the transpenet ingress port modify cf by (cf - ingress timestamp) and egress prot modify cf by (cf + egress timestamp)?

[vladimiroltean]

A and B has same timebase by other way

How?

sometimes there are devices which does not support 1588 or 802.1as. that is A ------->clouds---->B.

At least 802.1AS requires that all nodes in the network are time-aware. What tunneling protocol do you want to use, VXLAN?

if ptp4l update cf field on ingress and egress port independenty, then it can handle this case.

Explain how. It doesn't make sense. You want device A to transmit a PTP event message with a negative correctionField, and device B to fix it up? What protocol runs between device A and B? Certainly not IEEE 1588/802.1AS. You're looking at a custom protocol here.

[hi123ping]

we use vxlan.

"You want device A to transmit a PTP event message with a negative correctionField, and device B to fix it up? " yes, that is the case.

[vladimiroltean]

I don't know of a PTP-compliant way, sorry. Explain your use case to linuxptp-users@lists.sourceforge.net and maybe somebody can guide you. The ptp4l transparent clock assumes that the ingress and the egress ports share the same PTP hardware clock, and are controlled by the same Linux system in the same network namespace (how surprising).

[hi123ping]

A and B has same timebase by other way

How? A and B can get gps.

sometimes there are devices which does not support 1588 or 802.1as. that is A ------->clouds---->B.

At least 802.1AS requires that all nodes in the network are time-aware. What tunneling protocol do you want to use, VXLAN? vxlan

if ptp4l update cf field on ingress and egress port independenty, then it can handle this case.

Explain how. It doesn't make sense. You want device A to transmit a PTP event message with a negative correctionField, and device B to fix it up? What protocol runs between device A and B? Certainly not IEEE 1588/802.1AS. You're looking at a custom protocol here.

ingress port modify cf by (cf - ingress timestamp) and egress port modify cf by (cf + egress timestamp)

[hi123ping]

I don't know of a PTP-compliant way, sorry. Explain your use case to linuxptp-users@lists.sourceforge.net and maybe somebody can guide you. The ptp4l transparent clock assumes that the ingress and the egress ports share the same PTP hardware clock, and are controlled by the same Linux system in the same network namespace (how surprising).

ok. thanks

[vladimiroltean]

Understood. I don't know whether the PTP message format is suitable for this "backplane link" sort of application. For example, the correctionField is 8 bytes wide, but it holds a value in nanoseconds multiplied by 2^16. For example, 2.5 ns is represented as 0x0000000000028000. I haven't run the math, but if you intend on writing the 64-bit raw timestamps from your devices into the correctionField, you may run into wraparound issues.