Hello folks,
Me and my colleague are trying to get 1-step P2P & E2E Transparent Clock to
work, although so far with insignificant progress.
What we have succeeded with by now is 1-step P2P & E2E Ordinary Clock, in both
Master and Slave configurations, just as well as 2-step P2P & E2E Ordinary and
Transparent clock.
Our current hurdle is 1-step operation on P2P & E2E Transparent Clock.
To begin with, here’s what we have:
1-step capable hardware
Linux kernel v4.19 (We are well aware that it does not have support for
HWTSTAMP_TX_ONESTEP_P2P, and we are fine to run with HWTSTAMP_TX_ONESTEP_SYNC
to begin with, until we upgrade to latest-and-greatest LTS)
Linuxptp v3.1
The following entries constitute TC’s config file:
*****************************************
[global]
time_stamping onestep
clock_type P2P_TC
delay_mechanism P2P
priority1 200
free_running 1
freq_est_interval 1
tx_timestamp_timeout 100
[eth23]
network_transport L2
[eth24]
network_transport L2
*****************************************
Our setup (all entities run 1-step, either P2P or E2E mode):
OC-master <—> TC <—> OC-slave
Our observations so far:
OC-master sends SYNC packet and it reaches TC;
TC identifies it as 1-step SYNC, converts it to 2-step SYNC and creates a
Followup message, which is backed by the following lines, excerpted from
tc.c:tc_fwd_sync():
if (one_step(msg)) {
fup = msg_allocate();
if (!fup) {
return -1;
}
fup->header.tsmt = FOLLOW_UP | (msg->header.tsmt & 0xf0);
fup->header.ver = msg->header.ver;
fup->header.messageLength = sizeof(struct follow_up_msg);
fup->header.domainNumber = msg->header.domainNumber;
fup->header.sourcePortIdentity = msg->header.sourcePortIdentity;
fup->header.sequenceId = msg->header.sequenceId;
fup->header.control = CTL_FOLLOW_UP;
fup->header.logMessageInterval = msg->header.logMessageInterval;
fup->follow_up.preciseOriginTimestamp = msg->sync.originTimestamp;
msg->header.flagField[0] |= TWO_STEP;
}
TC goes forth and forwards newly converted 2-step SYNC to OC-slave
TC then proceeds and tries to fetch a timestamp for our 2-step SYNC message and
is nicely presented with error code from kernel. No surprise, hardware operates
in 1-step mode, so no timestamp is available in socket error queue)
TC, as the result of error, never sends its Followup message to OC-slave.
OC-slave, on the other side of the cable, receives 2-step SYNC message, and,
consequently, waits for the Followup, which is never to come.
The flow of messages we observe point out to a case where there is a mix of 1
and 2-step capable devices, such as 1-step OC-master, sending 1-step SYNC
packets to 2-step TCs and OCs.
Hence, our major concern still remains: is there something we have missed? Can
TC operate in 1-step mode out-of-the-box? Is there anyone out there running
1-step TC?
We would really appreciate some constructive feedback, with references to
configuration options and also code, where it is appropriate.
Thanks in advance gentleman.
/Volodymyr_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
