Hello, As per [BPI-R4 Pro] General questions & Mainline - #50 by system64
I’ve been experiencing awful performance with the 10 gigabit port on the mxl switch.
Now i’m not sure if this is due to my PC having a 5 gigabit port or not but it could be, Because according to ethtool the 10 gigabit port is running at an unadvertised and unsupported speed of 5000.
I’m using a custom artix linux rootfs but with this 6.18 kernel.
From my testing performance on mxl_lan4 (the 10 gigabit lan port) can be increased by setting scatter gather off on eth2 ethtool -K eth2 sg off
This makes receiving more stable (I get about 4.7~ gbit) but transmission is capped at gigabit speed (941~ mbit)
That also has the downside of completely nuking the performance for everything else on the mxl switch and causes a lot of retries.
Note that i have my bpi r4 pro connected to a 3A power adapter so this could very likely be a power issue, Though i did stress test the mxl switch and was able to fully saturate it without any power issues (9.6~ gbit total throughput)
Got a 5A brick on the way, Will re-test again once it’s here.
There are some known issues with the aeonsemi driver i use in my repo. There were some recent changes in sdk driver which may fix these,but i had bot found time to look further into it. At least the debug parts should not be used in production.
Have you tested the mxl switch throughput against mac/cpu or internal (port 2 port)?
Here’s how i conducted my stress test:
I connected 4 machines to the 4 mxl_lan ports 0-3 which are 2.5 gigabit
2 of the machines were 2.5 gigabit capable and the other 2 had only gigabit
I ran iperf3 -s on each of those machines, Then iperf3 -Z --skip-rx-copy --bidir -c ip.of.client.1 --json --logfile /tmp/result1.json for each one and summed up the combined throughput (in/out) and was able to basically max out the 10 gigabit USXGMII interface at about 9.3 to 9.7 gbit/s with little to no retries (about 36)
So you only check internal throughput of the switch and summarize rx+tx (which should be 10gbit/s in both directions). If you have 2x2.5G and 2x1G there is only 7G bidirectional and without the usxgmii uplink as it is forwarding internally. But nethertheless,back to the core question.
If you can add the current phy sdk driver (1.9.2 you should update also the firmware in utils/firmware) and test the phy again it would be nice.
Alright, Doubt i would have the time to do that myself, Maybe in a few days.
Send me a link to the driver and i’ll try it out. (If i manage to get it working)
I’ve decided i can spare some time to do a quick test, I’ve never done anything with openwrt’s patch list nor do i understand how these patches are supposed to work so i tried my best and just replaced: as21x1x_fw.bin, as21xxx.c, as21xxx.h.
The board booted and detected the new firmware but the performance issues are still there.
99% sure this is because i didn’t properly apply the new files and i might be missing something.
Afaik all files have to be put from target/linux/mediatek/files-6.6 into the tarted foldr (also the bbu_api) then the patch file has to be applied and then build,whichay throw errors due to different kernel versions.
Has anyone tried the openwrt with mtk feed yet?
i wonder why the files are all in drivers/net/phy/as21xxx but patch changes/creates all files again directly in drivers/net/phy (makefile also do not point to the as21xxx folder).
I also encountered a similar throughput issue when using firmware compiled from the officially source code.
In the upload direction (PC → LAN → WAN),only around 1 Gbps, while OpenWrt → WAN reaches 4 Gbps+
I’m not sure why this happens yet and I’m gathering more information.
afaik bpi code uses code for 1.8.5 firmware so have not the latest 2-3 rounds of changes which are reported as fixing some bugs
i have added the files from mtk-feed to 6.19-as21_192 branch, reverted previous changes and applied the patchfile, no compile-test yet
edit: seems to work so far (takes some time to get phy up ~40s, but the i can ping my router):
[ 7.742806] Aeonsemi AS21xxx mdio-bus:18: Firmware Version: 1.9.2
[ 11.887731] Aeonsemi AS21xxx mdio-bus:1c: Firmware Version: 1.9.2
...
root@bpi-r4-pro:~
$ ip link set lan4 up
[ 107.587893] mtk_soc_eth 15100000.ethernet eth2: configuring for fixed/10gbase-r link mode
[ 107.613345] mxl862xx mdio-bus:10 lan4: configuring for fixed/usxgmii link mode
[ 107.620884] mxl862xx mdio-bus:10 lan4: Link is Up - 10Gbps/Full - flow control off
[ 107.628556] mxl862xx mdio-bus:10 lan4: Link is Down
root@bpi-r4-pro:~
$ [ 107.647757] Aeonsemi AS21xxx mdio-bus:18: Firmware Version: 1.9.2
[ 107.649926] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control rx/tx
[ 107.743088] mxl862xx mdio-bus:10 lan4: PHY [mdio-bus:18] driver [Aeonsemi AS21xxx] (irq=POLL)
[ 107.751670] mxl862xx mdio-bus:10 lan4: configuring for phy/10gbase-r link mode
[ 107.788856] mxl862xx mdio-bus:10: failed to set intf on port 12 (hw:13,ser_port_id:1) to 2 (ret:-110)
[ 107.798086] mxl862xx mdio-bus:10: dsa mux: switch to channel1
...
$ [ 148.527820] mxl862xx mdio-bus:10 lan4: Link is Up - 100Mbps/Full - flow control rx/tx
root@bpi-r4-pro:~
$ ping 192.168.0.11
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.
64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=0.460 ms
64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=0.184 ms
64 bytes from 192.168.0.11: icmp_seq=3 ttl=64 time=0.200 ms
64 bytes from 192.168.0.11: icmp_seq=4 ttl=64 time=0.214 ms
64 bytes from 192.168.0.11: icmp_seq=5 ttl=64 time=0.226 ms
^C
--- 192.168.0.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4177ms
rtt min/avg/max/mdev = 0.184/0.256/0.460/0.102 ms
Thanks for the response!
I saw your commit on GitHub from a few hours ago.
I’ll find some time to test it over the next few days and will get back to you here.
Thanks for your maintenance and updates!
Just tested the new 1.9.2 firmware and i saw no change in behavior.
Maybe even a bit worse since it’s using more CPU % now and reaches about 3 gbit rx, Forgot to test tx but it still died and gave 0.00mbit/s when doing a --bidir test
Odd, Maybe it’s because i was testing a 5 gigabit link?
The speed is 4.7 initially maxing out a single core like yours but it very quickly drops to 3.1~ gbit
I tested both eth1 and lan4 (So both 10 gig ports)
