[Linuxptp-devel] Hybrid 1-step / 2-step P2P systems and ptp4l

[Andrew Symington]

Hi there

Up until now I have used BeagleBone Black as ordinary clocks connected by a
Moxa EDS-405A-PTP switch as a transparent clock. Both of these devices only
support 2-step time stamping, and P2P over 802.3 works out of the box with
the following command: ./ptp4l -i eth0 -2 -H -P -m

I have now moved to using a Ruggedcom RSG2488 switch, which supports 1-step
time stamping. I configured this switch an 802.3 P2P transparent clock, but
there is no option to configure 1 or 2 step mode. Although path delays
between to each BeagleBone is calculated correctly by the switch (I can
confirm this with the management interface on the switch), my problem is
that the Sync / Follow_up packets sent between BeagleBones don't seem to be
received and/or processed by ptp4l.

On closer examination of the packets using wireshark I noticed that the
RSG2488 was modifying the correction field of the Sync message rather than
the Follow_Up message. By contrast, the Moxa switch rather modified the
correction field of the Follow_Up message. The same pattern is true for the
Path_Delay_Resp and Path_Delay_Resp_Follow_up messages. I'm not certain if
this was the reason ptp4l did not appear to receive any Sync messages from
Slave

Can anybody please confirm whether it is normal behaviour for ptp4l, or if
it is likely a configuration / firmware issue with my switch? I have
included some ptp4l traces below, and the packet dump is available here:
http://filebin.ca/2LgrZ4ShbY56

I am using linuxptp 1.6-00001-g6eec5a0.

Regards
Andrew Symington


// MASTER
/////////////////////////////////////////////////////////////////////////

ptp4l[70013.985]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[70013.985]: selected best master clock 6ceceb.fffe.ab03b4
ptp4l[70013.985]: assuming the grand master role
ptp4l[70013.986]: port 1: master tx announce timeout
ptp4l[70014.049]: port 1: new foreign master 6ceceb.fffe.aef74d-1
ptp4l[70014.460]: port 0: announce timeout
ptp4l[70014.657]: port 1: delay timeout
ptp4l[70014.985]: port 1: master sync timeout
ptp4l[70015.658]: port 1: delay timeout
ptp4l[70015.986]: port 1: master sync timeout
ptp4l[70015.987]: port 1: master tx announce timeout

// SLAVE
/////////////////////////////////////////////////////////////////////////

ptp4l[70015.920]: selected best master clock 6ceceb.fffe.ab03b4
ptp4l[70015.921]: port 1: MASTER to UNCALIBRATED on RS_SLAVE
ptp4l[70016.539]: port 1: delay timeout
ptp4l[70016.927]: port 0: announce timeout
ptp4l[70017.540]: port 1: delay timeout
ptp4l[70018.541]: port 1: delay timeout
ptp4l[70019.541]: port 1: delay timeout
ptp4l[70020.542]: port 1: delay timeout
ptp4l[70021.542]: port 1: delay timeout
ptp4l[70022.543]: port 1: delay timeout
ptp4l[70023.543]: port 1: delay timeout

/////////////////////////////////////////////////////////////////////////////////

[Richard Cochran]

On Fri, Nov 06, 2015 at 07:44:02PM -0800, Andrew Symington wrote:
...

Post by Andrew Symington
On closer examination of the packets using wireshark I noticed that the
RSG2488 was modifying the correction field of the Sync message rather than
the Follow_Up message.

This is okay, since both correction fields are used to figure the offset.

Post by Andrew Symington
Can anybody please confirm whether it is normal behaviour for ptp4l, or if
it is likely a configuration / firmware issue with my switch? I have
http://filebin.ca/2LgrZ4ShbY56
I am using linuxptp 1.6-00001-g6eec5a0.

The problem is in the peer delay calculation. The function,
tsproc_update_delay requires four non-zero time stamps. However, when
using one step, two of the time stamps are zero. So this looks like a
bug in the 'tsproc' code which was introduced in v1.6.

Can you please try v1.5 to confirm?

Thanks,
Richard

------------------------------------------------------------------------------

[Miroslav Lichvar]

Post by Richard Cochran
The problem is in the peer delay calculation. The function,
tsproc_update_delay requires four non-zero time stamps. However, when
using one step, two of the time stamps are zero. So this looks like a
bug in the 'tsproc' code which was introduced in v1.6.

Hm, I'm not sure I follow. Which of the four timestamps are allowed to
be zero and how it's related to the one-step mode? If some timestamps
are zero I'd expect the problem to rather be a missing or extra
tsproc_down_ts/tsproc_up_ts call.

[Richard Cochran]

Post by Miroslav Lichvar
Hm, I'm not sure I follow. Which of the four timestamps are allowed to
be zero and how it's related to the one-step mode? If some timestamps
are zero I'd expect the problem to rather be a missing or extra
tsproc_down_ts/tsproc_up_ts call.

For P2P one step, you get t1 from PDelay_Req and t4 from PDelay_Resp.
The value (t3-t2) is provided in the correction field of the
PDelay_Resp.

thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar
Hm, I'm not sure I follow. Which of the four timestamps are allowed to
be zero and how it's related to the one-step mode? If some timestamps
are zero I'd expect the problem to rather be a missing or extra
tsproc_down_ts/tsproc_up_ts call.

For P2P one step, you get t1 from PDelay_Req and t4 from PDelay_Resp.
The value (t3-t2) is provided in the correction field of the
PDelay_Resp.

Ok, I think I see now. With a one-step clock there is no way to
transfer t3 in the pdelay response, only the t3-t2 difference, so t2
is set to zero and t3 is assumed to be equal to that. With a two-step
clock t2 and t3 can be transferred, but it's not a requirement and
they can actually be zero too.

So I guess the fix could be one of the following:
- modify tsproc_update_delay() to not require that t1 and t4 are
non-zero
- set t2 and t3 in port_peer_delay() to any non-zero value to indicate
to tsproc they are valid
- if the correction can be assumed to be always non-zero, in
port_peer_delay() apply half of it to t2 and half to t3