On Tue, Mar 28, 2023 at 03:54:50PM +0200, Riccardo Laiolo wrote:
> Thanks for your reply,
> why are you saying there's no IP support? I thought ethtool was saying
> there is both L2 and L4 filtering capabilities.
> > Hardware Receive Filter Modes:
> > none
> > ptpv2-l4-event
> > ptpv2-l4-sync
> > ptpv2-l4-delay-req
> > ptpv2-l2-event
> > ptpv2-l2-sync
> > ptpv2-l2-delay-req
> > ptpv2-event
> > ptpv2-sync
> > ptpv2-delay-req
ah, ok, I didn't notice it :)
so with PTP over IP, you'll also need these kernel config options and
commands for the software bridge to leave PTP traffic on the bridge
ports (so ptp4l can process it), and not "steal" it.
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE_EBT_BROUTE=y
CONFIG_BRIDGE_EBT_T_FILTER=y
CONFIG_BRIDGE_EBT_IP=y
CONFIG_BRIDGE_EBT_IP6=y
/sbin/ebtables --table broute --append BROUTING --protocol 0x88F7 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol
udp --ip-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol
udp --ip-destination-port 319 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD
--ip6-protocol udp --ip6-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD
--ip6-protocol udp --ip6-destination-port 319 --jump DROP
> > PTP hardware timestamping does not work on a bridge interface, for the
> > same basic reason that a bridge forwards packets to potentially multiple
> > ports, and it is not immediately clear, when an application sees a
> > timestamp coming from a bridge interface, which bridge port took that
> > timestamp (they may have different PHCs).
> >
> > This only leaves you a single option:
> >
> > ptp4l -i lan1 -i lan2 -i lan3 [ ... ] -2 -P -m --tx_timestamp_timeout 40
>
> Finally, I tried to launch ptp4l on my board as master (on all of the
> front-facing port)
> with -2 and it's working as expected, since all the (slave-only) devices are
> synchronising to it.
>
> On the other hand if I configure my board as a slave-only device (-s flag)
> it's not working.
> I've attached two logs, in the first one i launched ptp4l with -i on all
> ports,
> but it's noisy and unreadable!
> Anyway, the master was on port3 and on port5 was a second slave.
> In the second one i passed -i lan3 (the port connected directly to the ptp
> master device)
| ptp4l[2095.455]: master offset 17973 s2 freq +1000000 path delay
369
This "freq +1000000" is odd. Who plays the role of the PTP master?
Its clock is running way too fast, the switch can't keep up with it.
If it's linuxptp-based, you can reset its frequency with
"phc_ctl /dev/ptp0 freq 0" and that should get things back to normal
(unless the PHC of the master is under the control of another process
which is persistently causing this).
| ptp4l[1857.988]: timed out while polling for tx timestamp
| ptp4l[1857.988]: increasing tx_timestamp_timeout may correct this issue, but
it is likely caused by a driver bug
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)?
commit f166f890c8f026a931e1bb80f51561a1d2f41b27
Author: Andrew Lunn <and...@lunn.ch>
Date: Sat May 2 17:25:04 2020 +0200
net: ethernet: fec: Replace interrupt driven MDIO with polled IO
Measurements of the MDIO bus have shown that driving the MDIO bus
using interrupts is slow. Back to back MDIO transactions take about
90us, with 25us spent performing the transaction, and the remainder of
the time the bus is idle.
Replacing the completion interrupt with polled IO results in back to
back transactions of 40us. The polling loop waiting for the hardware
to complete the transaction takes around 28us. Which suggests
interrupt handling has an overhead of 50us, and polled IO nearly
halves this overhead, and doubles the MDIO performance.
Care has to be taken when setting the MII_SPEED register, or it can
trigger an MII event> That then upsets the polling, due to an
unexpected pending event.
Suggested-by: Chris Heally <cphe...@gmail.com>
Signed-off-by: Andrew Lunn <and...@lunn.ch>
Signed-off-by: David S. Miller <da...@davemloft.net>
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
