Openwrt is hard to trace because there are many backports from later kernel versions…i experience on 5.6 that trgmii does not work where it does work for me on 5.4…so try applying the 2 Patches (or change to rgmii twice) and test again
I think those 2 patches are already merged into the main 5.4 kernel tree. I see this on the release notes for kernel 5.4.34 https://lwn.net/Articles/818234/. On the latest OpenWRT compiled image I was running version 5.4.39 which I guess includes also these patches.
René van Dorst (2):
net: dsa: mt7530: move mt7623 settings out off the mt7530
net: ethernet: mediatek: move mt7623 settings out off the mt7530Right, i see it’s already merged in 5.4 committed by gregkh…so this should not be not the cause…found also no other change to soc- and switchdriver which may cause a performance-drop
Just to your information, i flashed beta4 image:
openmptcprouter-v0.55beta4-r0+13235-eb17ee294c-mediatek-mt7623-bpi_bananapi-r2-ext4-sdcard
the kernel is: 5.4.41
and LAN speed is still very low.
Ysurac (developer of OpenMPTCProuter) told me on OpenMPTCProuter issues page:
I’m testing patches for next beta
(but I thing he is talking about patches which you mentioned in this topic)
I saw yesterday a new patch related to VLAN was applied in the latest 5.4 kernel tree and I guess it will be available in the next release.
https://patchwork.kernel.org/patch/11552461/
Allow DSA to add VLAN entries even if VLAN filtering is disabled, so enabling it will not block the traffic of existent ports in the bridge
I’m not sure if this is related to the traffic slowness I have not tested it.
tested with 5.7-rc4 and 5.4.39-main
have massive retransmits, sometimes it’s better, than worse again (running multiple iperf3 tests)…retransmits happening mostly in the first blocks…
root@bpi-r2:~# iperf3 -c 192.168.0.21
Connecting to host 192.168.0.21, port 5201
[ 5] local 192.168.0.11 port 49882 connected to 192.168.0.21 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 15.2 MBytes 128 Mbits/sec 355 14.1 KBytes
[ 5] 1.00-2.00 sec 67.0 MBytes 562 Mbits/sec 150 424 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 942 Mbits/sec 0 427 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 940 Mbits/sec 0 430 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 944 Mbits/sec 6 455 KBytes
[ 5] 5.00-6.01 sec 113 MBytes 943 Mbits/sec 0 495 KBytes
[ 5] 6.01-7.00 sec 112 MBytes 944 Mbits/sec 0 508 KBytes
[ 5] 7.00-8.01 sec 112 MBytes 941 Mbits/sec 0 510 KBytes
[ 5] 8.01-9.00 sec 111 MBytes 938 Mbits/sec 0 515 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 11 331 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 980 MBytes 822 Mbits/sec 522 sender
[ 5] 0.00-10.01 sec 979 MBytes 821 Mbits/sec receiver
i have this too on 5.4.27 (where switch port 6 and gmac is set to rgmii…not trgmii)…flowcontrol is enabled on both switch-ports (laptop,r2), thtool reports on both devices
Link partner advertised pause frame use: Symmetric
it looks like incoming traffic on dsa-port is dropped (but not as much as the retransmits…having ~1000 retransmitts but only 2 dropped packets on lan0 rx, other side shows no drops, eth0 also clean)
5: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
mode DEFAULT group default qlen 1000
link/ether 08:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
60687057 1163551 0 128 0 0
TX: bytes packets errors dropped carrier collsns
3791310361 106713 0 0 0 0
it looks like my retransmitts are caused by ubuntu 20.4 with kernel 5.4.0-29…if i run test in ubuntu 18.4 (5.3) i have no retransmitts, same network-cables,switchports,hardware. let r2 running while rebooting my laptop to ubuntu 20.4 i get retransmitts again. Tested my 5.4.39-main…works without retransmits in ubuntu 18.4
So it looks more than ubuntu 20.4 issue on my laptop instead of bpi-r2 kernel issue