Hello,
I'm experimenting with a standalone managed switch based on Microchip
KSZ9477 (particularly this switch:
https://cdn.shopify.com/s/files/1/0577/8705/6295/files/GigaStax_RevB77_DataSheet.docx_1.pdf?v=1645556114
) and I see some unexpected behavior of linuxptp (master branch). I'd be
glad if someone has ideas on what to configure to get a steady sync.
The KSZ chip has some weird design decisions and errata discussed in
detail in the netdev discussion:
https://patchwork.ozlabs.org/project/netdev/patch/20201019172435.4416-8-cegg...@arri.de/#2558824
. To summarize it - it can be configured to work as either E2E TC or P2P
TC, one-step only (two-step supported but broken). It also has a
mysterious "master/slave" bit which somehow specifies which PTP events
are forwarded and which are not. However, setting it to the master mode
results in not forwarding SYNC packets (among others), so I do not even
try this mode further.
I can't get the P2P TC mode working at all, as there's never a single
PDelay_Req or PDelay_Resp packet generated by the switch (but it
correctly does not forward these packets when received at ingress). I'll
try to resolve this with the switch manufacturer as I don't see much
that could be done by the Linuxptp community (but please tell me if you
have experience with this!).
So I'm left with E2E one-step TC mode. Good news is that it correctly
lets all PTP event packets pass through and adds corrections to SYNC,
PDELAY_REQ, PDELAY_RESP and DELAY_REQ packets (I know PDELAY* are not
needed in E2E, but I just tested it also adds corrections to these in
the E2E TC mode). I looked at the corrections and they seem reasonable -
they're all around 1480 ns. What I don't understand is that I can't get
ptp4l to converge once I turn on adding these corrections. When PTP mode
is turned off in the switch, I quickly get to master offsets in the
order of ~1000 ns, path delay about 38000 ns. But when I turn filling
the corrections on, it seems linuxptp is really struggling to understand
what is going on. The master offset always oscillates in the order of
millions, as well as the estimated path delay. What can be a reason for
this happening? I'm testing this with default.cfg, and also with our
customized "Automotive profile with E2E delay mechanism". Both behave
the same in this regard. The testing setup consists of two computers
connected via the switch, each computer having a
hardware-timestamping-capable NIC.
The only idea I came with is that the computers are two-step clocks,
while the switch behaves as one-step clock. But I thought this does not
matter to the PTP protocol.
Thank you for any ideas!
Martin
--
Mgr. Martin Pecka, Ph.D.
Researcher at Vision for Robotics and Autonomous Systems group
Faculty of Electrical Engineering
Czech Technical University in Prague
Phone: +420 22435 7269
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
