linuxptp-users

[Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

Hi all,

I have two gPTP aware switches here and a PC with i210 and with switch A
ptp4l is syncing fine, while with switch B not. Could anybody point me in a
direction how I can find out what ptp4l doesn't like regarding switch B. It
always selects itself as best master continously (i210 MAC is
a0-36-9f-47-60-48). Prios are the same for switch A and B.

Here's the output (first part switch A, second switch B):
ptp@T20-1-Linux:~/Projects/linuxptp-1.5$ sudo ./ptp4l -f gPTP.cfg -i eth0 -s
-m -q
ptp4l[1342.478]: selected /dev/ptp0 as PTP clock
ptp4l[1342.504]: driver changed our HWTSTAMP options
ptp4l[1342.504]: tx_type   1 not 1
ptp4l[1342.504]: rx_filter 1 not 12
ptp4l[1342.504]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1342.504]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1345.544]: port 1: new foreign master 200cc8.fffe.3e281a-15
ptp4l[1347.544]: selected best master clock 200cc8.fffe.3e281a
ptp4l[1347.544]: running in a temporal vortex
ptp4l[1347.544]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1348.785]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1349.105]: rms 19429 max 31010 freq -52740 +/- 4284 delay   576 +/-
0
ptp4l[1349.745]: rms 1638 max 3060 freq -53035 +/- 1223 delay   577 +/-   0
ptp4l[1350.385]: rms 1517 max 1937 freq -49043 +/- 985
ptp4l[1351.025]: rms 1907 max 1995 freq -46535 +/- 455 delay   578 +/-   0
ptp4l[1351.665]: rms 1269 max 1617 freq -45749 +/-  49 delay   579 +/-   0
ptp4l[1352.305]: rms  465 max  751 freq -46029 +/- 158
ptp4l[1352.945]: rms  146 max  237 freq -46624 +/- 165 delay   578 +/-   0
ptp4l[1353.585]: rms  276 max  287 freq -47079 +/-  97 delay   578 +/-   0
ptp4l[1354.225]: rms  225 max  267 freq -47280 +/-  24
ptp4l[1354.865]: rms  105 max  152 freq -47279 +/-  18 delay   576 +/-   0

ptp@T20-1-Linux:~/Projects/linuxptp-1.5$ sudo ./ptp4l -f gPTP.cfg -i eth0 -s
-m -q
ptp4l[1390.190]: selected /dev/ptp0 as PTP clock
ptp4l[1390.212]: driver changed our HWTSTAMP options
ptp4l[1390.212]: tx_type   1 not 1
ptp4l[1390.212]: rx_filter 1 not 12
ptp4l[1390.212]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1390.212]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1397.925]: selected best master clock a0369f.fffe.476048
ptp4l[1403.991]: selected best master clock a0369f.fffe.476048
ptp4l[1411.821]: selected best master clock a0369f.fffe.476048
ptp4l[1419.027]: selected best master clock a0369f.fffe.476048
ptp4l[1425.377]: selected best master clock a0369f.fffe.476048
ptp4l[1433.077]: selected best master clock a0369f.fffe.476048
ptp4l[1440.106]: selected best master clock a0369f.fffe.476048
ptp4l[1447.154]: selected best master clock a0369f.fffe.476048
ptp4l[1454.366]: selected best master clock a0369f.fffe.476048

Thank you
Axel

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Richard C. <ric...@gm...>]

On Thu, Feb 19, 2015 at 02:00:16PM +0100, Axel Holzinger wrote:
> Hi all,
> 
> I have two gPTP aware switches here and a PC with i210 and with switch A
> ptp4l is syncing fine, while with switch B not. Could anybody point me in a
> direction how I can find out what ptp4l doesn't like regarding switch B. It
> always selects itself as best master continously (i210 MAC is
> a0-36-9f-47-60-48). Prios are the same for switch A and B.

Increase the message level to take a look at the asCapable port
variable.  There are quite a number of conditions.

Some other ideas:

Use wireshark to find out what, if any, messages are being exchanged.

In port.c, there are quite a few places where silently we drop invalid
messages.  You can hack in a few debugging statements to find out what
is going on, especially WRT asCapable.

Good luck,
Richard

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

On Thu, Feb 19, 2015 at 04:05PM +0100, Richard Cochran wrote:
> On Thu, Feb 19, 2015 at 02:00:16PM +0100, Axel Holzinger wrote:
> > Hi all,
> >
> > I have two gPTP aware switches here and a PC with i210 and with switch A
> > ptp4l is syncing fine, while with switch B not. Could anybody point me
in a
> > direction how I can find out what ptp4l doesn't like regarding switch B.
It
> > always selects itself as best master continously (i210 MAC is
> > a0-36-9f-47-60-48). Prios are the same for switch A and B.
> 
> Increase the message level to take a look at the asCapable port
> variable.  There are quite a number of conditions.
> 
> Some other ideas:
> 
> Use wireshark to find out what, if any, messages are being exchanged.
> 
> In port.c, there are quite a few places where silently we drop invalid
> messages.  You can hack in a few debugging statements to find out what
> is going on, especially WRT asCapable.

Well, it was a combination of all three tips. Finally I found out that
gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
trace TLV. That was the reason for ptp4l to drop the announce message.

Thanks a lot!
Axel

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Richard C. <ric...@gm...>]

On Thu, Feb 19, 2015 at 08:03:51PM +0100, Axel Holzinger wrote:
> 
> Well, it was a combination of all three tips. Finally I found out that
> gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
> trace TLV. That was the reason for ptp4l to drop the announce message.

Switch B is non-compliant with 802.1-AS-2011.  The path trace TLV is
required by clause 10.5.3.2.8 on page 91 and by F.3 g) on page 272.

Thanks,
Richard

Re: [Linuxptp-users] PTP4L syncing on (gPTP aware) switch A, but not B

[Axel H. <aho...@gm...>]

On Thu, Feb 19, 2015 at 08:29PM, Richard Cochran wrote:

> On Thu, Feb 19, 2015 at 08:03:51PM +0100, Axel Holzinger wrote:
> >
> > Well, it was a combination of all three tips. Finally I found out that
> > gPTP.cfg sets path_trace_enabled to 1 while switch B doesn't send a path
> > trace TLV. That was the reason for ptp4l to drop the announce message.
> 
> Switch B is non-compliant with 802.1-AS-2011.  The path trace TLV is
> required by clause 10.5.3.2.8 on page 91 and by F.3 g) on page 272.

Thank you Richard. I informed the manufacturer. I'll report back.

Regards
Axel