On Wed, Mar 29, 2023 at 02:35:56PM +0200, Riccardo Laiolo wrote: > Those kernel options were unselected. I've recompiled the kernel. Still not > working. > > On A I'm running ptp4l on IPv4 transport and highest priority (so, always > grand master). > > On B, ptp4l with standard priority don't see any master on the network and > promotes itself as gm. > On A I see there is a new master, but A remains gm due to higher priority. > > A log: > root@imx8mp-var-dart:~# ptp4l -i eth0 --tx_timestamp_timeout=40 -m -4 > --priority1=0 -P > > B log: (here you see i passed two lan ports to force boundary clock mode, > don't know if this is relevant. Anyway, there was ptp traffic on lan2 only) > > It looks like outgoing ptp packets get routed fine while incoming ones get > ignored/filtered/sucked-into-void
Start simple first. Remove the bridge. Use a single interface. Make sure you have an IP address on that interface. Then add things one by one. > Is there any downsides using -2 instead the default IPv4 transport? Define "downsides"? > > By the way sometimes I had some "port [n]: received SYNC without timestamp" > messages when using -2 that went away > when I added the broute on EtherType 0x88F7. I'm not sure that's related, but okay... > > Here, there may simply be too much MDIO traffic, and 40 ms is not enough > > to collect timestamps. Can you try increasing it more (100 ms)? > > > > What MDIO controller is this? The one from the FEC? If so, does your > > kernel have this patch (and related)? > > [...] > > On mdio bus the only devices are the controller and the Marvell switch. > Even increasing timeout to stupid values (>1000) I still get tx timestamp > timeout sometimes... > Simultaneously I get a "tx timestamp overrun" message from Marvell driver > module, maybe I can try to track that message > in driver code trying to figure out what's going on. > > We are not using FEC as eth controller, we are using eqos (dw-mac/stmmac ip) > instead. Do you know if there > are some bugs or patches related to ptp applications with this controller too? The stmmac driver is in a pretty sorry state, and things won't probably work well until inspected with a fine comb, and then an eye kept on it. I don't have any magic tricks for it. Maybe check the value of the "clk_csr" device tree property, which controls the MDIO frequency (MAC_MDIO_Address register, field CR - CSR Clock Range). There are some more interesting bits that this device has in its MAC_MDIO_Address register, like PSE (Preamble Suppression Enable), BTB (Back to Back transactions), NTC (Number of Trailing Clocks) which could potentially improve the MDIO throughput considerably. I'm talking about this sort of optimizations that are being applied to other MDIO controller drivers for transactions to take place quicker: https://patchwork.kernel.org/project/netdevbpf/cover/20220126160544.1179489-1-tob...@waldekranz.com/ But, as they say, some elbow grease will be required. _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
