thank you!
Has a pull request been created to include this modification in the next version?
Not yet, it's only there for snapshot for now.
The pull request is applied to the master branch!
6 Likes
Excellent. I'm excited to see this in a release.
Thank you so much for your work.
1 Like
Any plans/real chance for backport to 22.03?
Usually new features are not backported but since this is a devicetree only change, it may find its way to the current releases. It's all up to @hauke.
If it fixes some issue... Do we have an opened issue for this topic?
I always thought that it was 1000/1000. So now I'm wondering, how about other mediatek or qualcomm SoCs? Are they 1000/1000 or 500/500?
Hello arinc9,
If I understand correctly, all qualified MT7621 snapshots as of August 21, 2022 will contain your patch now?
That sounds correct, yes!
4 Likes
Thank-you.
Hello @arinc9,
I'm trying your patch for device Keenetic Giga 3 (wikidevi). But so far I don't have a very powerful CPU on which the ipefr3 -c localhost --bidir utility would show at least 2 Gbps.
After applying this patch, I noticed that the protocol type of the ports has changed from MII to Twisted Pair:
root@ZKG:/# ethtool lan1
Settings for lan1:
Supported ports: [ TP MII ]
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 3
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
root@ZKG:/# ethtool wan
Settings for wan:
Supported ports: [ TP MII ]
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 4
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Is this normal? And what does it say?
Why do you do this? Does the wan port not work after the changes? Also, why do you connect to localhost for speed test?
WAN port is work.
So I just tested the capabilities of my computer: ipefr3 -c localhost --bidir -t 15
Ok, I’ve never checked the output of ethtool so I don’t know what to tell you. If wan port works, I don’t see a problem.
when I use these devices as access points
I map the wan port back to the br-lan
so in this mode is the cpu now needed
to move traffic between wan and lan ports
or will it reattach it back to the switch ?
Yes, frames will go through the CPU for wan port.
1 Like
Verified snapshot build downloaded 24 August 2022, openwrt-ramips-mt7621-linksys_ea7500-v2-squashfs-factory.bin on, yes, a Linksys EA7500 v2:
Concurrent tests 172.18.64.148 (Core i5 Intel i340 igb diriver connected to "Internet" i.e. WAN port) <--> 172.18.1.94 (Core i7 Marvell sky2 driver connected to LAN 1 port). Both subnets /24 therefore routed.
Connecting to host 172.18.64.148, port 5201
[ 4] local 172.18.1.94 port 59426 connected to 172.18.64.148 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 113 MBytes 944 Mbits/sec 0 417 KBytes
[ 4] 1.00-2.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 2.00-3.00 sec 110 MBytes 927 Mbits/sec 0 417 KBytes
[ 4] 3.00-4.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 4.00-5.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 5.00-6.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 6.00-7.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 7.00-8.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 8.00-9.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 9.00-10.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 10.00-11.00 sec 110 MBytes 926 Mbits/sec 0 417 KBytes
[ 4] 11.00-12.00 sec 112 MBytes 938 Mbits/sec 0 658 KBytes
[ 4] 12.00-13.00 sec 110 MBytes 927 Mbits/sec 0 658 KBytes
[ 4] 13.00-14.00 sec 110 MBytes 926 Mbits/sec 0 658 KBytes
[ 4] 14.00-15.00 sec 110 MBytes 926 Mbits/sec 0 658 KBytes
[ 4] 15.00-16.00 sec 110 MBytes 927 Mbits/sec 0 658 KBytes
[ 4] 16.00-17.00 sec 110 MBytes 926 Mbits/sec 0 658 KBytes
[ 4] 17.00-18.00 sec 110 MBytes 926 Mbits/sec 0 658 KBytes
[ 4] 18.00-19.00 sec 110 MBytes 927 Mbits/sec 0 658 KBytes
[ 4] 19.00-20.00 sec 110 MBytes 926 Mbits/sec 0 658 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-20.00 sec 2.16 GBytes 928 Mbits/sec 0 sender
[ 4] 0.00-20.00 sec 2.16 GBytes 926 Mbits/sec receiver
iperf Done.
Connecting to host 172.18.1.94, port 5201
[ 5] local 172.18.64.148 port 52098 connected to 172.18.1.94 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 111 MBytes 934 Mbits/sec 0 638 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 638 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 638 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 932 Mbits/sec 0 638 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 933 Mbits/sec 0 638 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 638 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 943 Mbits/sec 0 638 KBytes
[ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 0 638 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 638 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 10.00-11.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 11.00-12.00 sec 112 MBytes 944 Mbits/sec 0 670 KBytes
[ 5] 12.00-13.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 13.00-14.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 14.00-15.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 15.00-16.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 16.00-17.00 sec 112 MBytes 944 Mbits/sec 0 670 KBytes
[ 5] 17.00-18.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 18.00-19.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
[ 5] 19.00-20.00 sec 111 MBytes 933 Mbits/sec 0 670 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 2.18 GBytes 935 Mbits/sec 0 sender
[ 5] 0.00-20.00 sec 2.17 GBytes 934 Mbits/sec receiver
iperf Done.
Also tested using LAN 3 port (removed from default bridge configured as above) in place of WAN. As might be expected, speed was slightly worse than halved, roughly 450/450.
Note: Again, the above tests were concurrent. Did it this way because the iperf3 version on one of the hosts did not support the --bidir option.
1 Like
Hi,
I try to understand this very interesting patch.
Before your patch:
- poor rooting perf in router mode (wan <-> br-lan)
- good switching perf in full bridged mode (br-lan containing all the interfaces WAN + LAN[1-x] as I do each time I use a router as an AP)
After your patch:
- good rooting perf (twice as before) in router mode (wan <-> lan)
- poor switching perf (half as before) between "WAN" device and "LANx" device in full bridged mode (br-lan containing all the interfaces WAN + LAN[1-x] )
So if I want to use an recent openwrt snapshot on a MT7621 compatible device as an AP/managed switch it should be really better to not use the WAN port as the uplink and reserve it for a device that consumes little bandwidth (printer/iot) ?
Am I right ?
I also ask that because I don't know where the wireless radio is "plugged" inside the hardware, so I don't know if is better to associate the wireless radio to bridge that uses the "wan" port or a lan port as the uplink (sorry, hard to explain for me in English, I hope you will understand my question) with the use of your patch
Regards
Edit:
I made a quick test on my Cudy WR1300.
Switching only (my use case acting as an AP/managed switch) with or without sw and hw offloading (same result)
- 22.03.0-rc6:
lan <=> wan:
lan <=> lan:
- Actual snapshot (r20386-15cae55cec):
lan <=> wan:
lan <=> lan:
So switching perf are altered with this patch as expected.
Is there any way to make it a "conditionnal patch" ?
Something like:
if "wan iface" not in br-lan
then "use this patch"
elseif "wan iface" in br-lan
then "don't use it"
or:
if hw offloading in use
then use this patch
elseif
then don't use it
sorry, I'm not a dev