[Linuxptp-users] large sync offsets connected through 802.1AS switch

[John Lemonovich]

Hello,



I have my 2 Altera A10 kits running LinuxPTP sync'd using HW timestamping
to < 60ns using UDP connected to a non PTP switch (with not much total
traffic). I am now connecting the same 2 kits through an ExtremeNetworks
802.1AS switch and have switched to L2 transport. After working through
some issues and finding out that transportSpecific must be set to 1 for
802.12AS capable to be reported in the transport specific field of the
frames, I have the master and slave sync'd again, and I see now the path
delays are much lower, but my offsets never converge and kind of move all
around. Would this be a PI tuning issue, or some other issue? I guess I
am confused by the constant positive numbers, as if the servo loop is not
running/working - there is no overshoot (no negative numbers ever). There
is also a possibility that something is wrong at the switch, it seems to
be reporting a gPTP role of master for both ports - even though they
clearly appear to be sync'd as master/slave.



As a side note I am trying to do my usual checks using the pmc, and it
will say 'SENDING' command, but nothing ever prints. So if I send ./pmc
-u -b 0 'GET TIME_STATUS_NP' I get --- sending: GET TIME_STATUS_NP'
but never anything else?



Here are some example prints from ptp4l:



ptp4l[17758.412]: rms 222663 max 391336 freq +156613 +/- 241080 delay
341 +/- 0

ptp4l[17759.411]: rms 180924 max 232414 freq -4532 +/- 201675 delay 324
+/- 0

ptp4l[17760.412]: rms 196355 max 244794 freq -174251 +/- 169979 delay
416 +/- 0

ptp4l[17761.412]: rms 285457 max 495634 freq +229499 +/- 236546 delay
416 +/- 0

ptp4l[17762.412]: rms 166655 max 240394 freq -84674 +/- 152154 delay 324
+/- 0

ptp4l[17763.421]: rms 153881 max 229134 freq -173488 +/- 127556 delay
324 +/- 0

ptp4l[17764.421]: rms 41950 max 61219 freq -78673 +/- 47652 delay 309
+/- 0

ptp4l[17765.421]: rms 52891 max 101421 freq -25297 +/- 37392 delay 309
+/- 0

ptp4l[17766.421]: rms 587756 max 1140716 freq +321506 +/- 611787 delay
294 +/- 0

ptp4l[17767.413]: rms 203478 max 304704 freq -175331 +/- 64623 delay 361
+/- 0

ptp4l[17768.422]: rms 299948 max 542729 freq +72125 +/- 339263 delay 378
+/- 0

ptp4l[17769.422]: rms 207489 max 375752 freq +68505 +/- 234100 delay 378
+/- 0

ptp4l[17770.431]: rms 130949 max 198888 freq -145241 +/- 79577 delay 378
+/- 0

ptp4l[17771.441]: rms 65818 max 98892 freq -58606 +/- 75996 delay 389
+/- 0

ptp4l[17772.441]: rms 100063 max 196601 freq +4824 +/- 103346 delay 406
+/- 0

ptp4l[17773.441]: rms 47420 max 92864 freq +7939 +/- 42395 delay 391
+/- 0

ptp4l[17774.441]: rms 33061 max 58259 freq +19838 +/- 25911 delay 391
+/- 0





Thank you for any assistance,



John

[Richard Cochran]

Post by John Lemonovich
I have my 2 Altera A10 kits running LinuxPTP sync'd using HW timestamping
to < 60ns using UDP connected to a non PTP switch (with not much total
traffic). I am now connecting the same 2 kits through an ExtremeNetworks
802.1AS switch and have switched to L2 transport. After working through
some issues and finding out that transportSpecific must be set to 1 for
802.12AS capable to be reported in the transport specific field of the
frames,

For 802.1AS, I recommend using the supplied gPTP.cfg configuration file.

Post by John Lemonovich
I have the master and slave sync'd again, and I see now the path
delays are much lower, but my offsets never converge and kind of move all
around. Would this be a PI tuning issue, or some other issue?

Sounds like a bug in the Altera A10 driver or HW. IIRC, there is no
mainline Linux support for that part.

Before you essentially had two identical units directly connected.
Now, with the AVB switch, now there is a third party. I guess that
the Altera bug is masked by symmetry in the first case.

You should verify that the switch is not to blame by testing it with
known good gPTP clients, for example a PC running ptp4l -f gPTP.cfg.

Thanks,
Richard