From: Marcin Miklas <marcin.mik...@harman.com>
Hi,
I've noticed couple of problems when using linuxptp with other gPTP
implementations.
gPTP requires that PTP_TIMESCALE flag is set in messages. I noticed that
PDelayReq, PDelayResp, PDelayRespFollowUp, Sync, FollowUp and Signaling all have
that flag set to 0. One of the bridges just ignores communication with ptp4l
because of that.
The fault is on both sides, because gPTP specification says that PTP_TIMESCALE
should be set to 1 and ignored on reception.
Since fixing linuxptp is easier I created a patch which should fix that problem.
flagField[1] was not set at all during messages construction. The patch is only
changing messages construction for gPTP relevant messages because only those I
could test.
Second thing I noticed, is a problem with signalling messages. When servo is
unlocked the following function is called:
port_tx_interval_request(p, SIGNAL_NO_CHANGE,
SIGNAL_SET_INITIAL,
SIGNAL_NO_CHANGE);
We can see that ptp4l slave is requesting gPTP master to use master's initial
sync interval. This might be different than slave's initial sync interval. If
this is a case the signallings will be send over and over again. Slave's own
initalLogSyncInterval should be used here.
Current version is causing other problems with OpenAvnu's daemon_cl.
SIGNAL_SET_INITAL has value 126 which is not interpreted as special value by
daemon_cl but treated literally, setting sync interval to 2.7E30 years therefore
disabling the sync interval sending.
Regards,
Marcin Miklas
*** BLURB HERE ***
Marcin Miklas (2):
Do not use SIGNAL_SET_INITIAL in Signaling messages
Add setting of PTP_TIMESCALE flag
port.c | 7 ++++++-
port_signaling.c | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
--
2.25.1
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
