Here's my test using MT7621 with Gigabit port
The device:
- PL100 (MT7621) and Intel Atom minipc (x86/64).
- Both using OpenWRT 21.02.2
- TP-Link Gigabit LAN Switch in between and Cat6 cable.
Unless I am mistaken, your setup is not measuring the WAN to LAN throughput on an individual openwrt device using iperf3.
iperf3 server -- (wan) openwrt router (lan) -- iperf3 client
Yes, the test is in intranet (LAN to LAN) not on the internet (WAN to LAN).
Both Iperf3 run on router side. Both router using OpenWRT iperf3 package downloaded from openwrt software repo.
My ISP limit the speed to less than 100Mbps.
Use WAN port on router and connect it to local PC/client and the LAN port connect to local client, run iperf on both client. I think this is sufficient to check the performance.
I have also measured a big drop in ethernet performance accompanied by a higher CPU. My test is in a HLK7621 board (mt7621 device without an external switch, only the embedded ethernet switch) using master commit f3fa68e515 from April 13.
Hello everyone,
Getting back on this thread as i was hoping the performances will be back to a kind of "normal" with the latest updates, it seems not.
I've updated my very little Cudy W1300, and even with Software Offloading activated, it's staying around 500mb/s rather than 800mb/s
And actually, activating the software offlloading made the connection very unstable, and disconnecting often.
Any tips since few months about that ?
Thanks
Hi.
Have you seen this thread ?
1 Like
Iirc, openwrt 21 had packet scheduling issues beyond 21.01 - the version which last used round-robin; fixes and reversion to round robin scheduler were not ported into 21 - as it's on security updates -only maintenance.
Thank you for the link ! Seems there is a good news on this, but it's way over my knowlege to use the patch or installing the snapshot, i will have to wait for the next stable release to got it.
Hi
It's easy to create a custom build based on the latest snapshot, using the image selector.
Remember to add luci to the packages list. Than you flash the image just like another one. You can keep the settings.
1 Like
Can confirm that the expected performance is back 
iperf -c 192.168.1.1 -u -b 990M --full-duplex
------------------------------------------------------------
Client connecting to 192.168.1.1, UDP port 5001
Sending 1470 byte datagrams, IPG target: 11.33 us (kalman adjust)
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.1.172 port 53568 connected with 192.168.1.1 port 5001 (full-duplex) (no-udp-fin)
recvmsg failed: Connection refused
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ *1] 0.0000-0.0009 sec 0.000 Bytes 0.000 bits/sec 0.000 ms 0/0 (-nan%)
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-10.0002 sec 1.11 GBytes 954 Mbits/sec
[ 1] Sent 811383 datagrams
[ ID] Interval Transfer Bandwidth Datagrams PPS
[SUM] 0.0000-10.0002 sec 1.11 GBytes 954 Mbits/sec 811383 81137 pps
[SUM-2] Sent 811383 datagrams
Hi.
You are testing wrongly.
From a device (192.168.1.172) to the router (192.168.1.1), it is only testing the LAN without routing. So the result (954Mbit/s) means that you are fully using a gigabit wire, which is totally expected.
You need to test from LAN to WAN in order to use the routing feature. You can simulate this by adding a computer to the WAN, but you need to manually edit IPs on both the router WAN port, and the computer.
1 Like
No, this is in line with my original report. I was also testing data being sourced to/from the 7621 device, not using NAT.
This is also what I expected, and was not getting in my original report. If you read this thread from the beginning, you'll see the topic of NAT was already brought up.
It is useful to test data going to and from the device, as this measures how fast the device can process (source and consume) data. In fact, this is generally harder on a device then NAT, because hardware NAT acceleration means the device doesn't have to process each packet in it's entirety.
I'm sorry, I got confused while trying to refocus on this topic.
1 Like
Hello everyone. Even after getting the last snapshot, i'm unable to go further than 500mb/s with my Cudy W1300 v1. Is the router is still underpowered even after the patch ?
Do i need to move the WAN port designation on a different port ?
Thank you
Right around 500 Mbps is what I got when I was using an ER-X on OpenWrt without hardware offload.
Performance loss is relative with the ER-X MT7621. An ER-X ran a little faster on older versions of OpenWrt as reported here, than on more current versions, but OpenWrt is still faster than stock EdgeOS.
1 Like
But this patch 2 Gbps WAN/LAN NAT Routing on ramips MT7621 devices seems to solve the problem for most of it, included in the last snapshots.
It might be not working on the Cudy WR1300, just trying to find out.
I think the purpose of that patch is to support NAT at up to 1 Gbps in two directions (full duplex) using hardware offload. Before the patch, total throughput in two directions at once was limited to 1 Gbps, for example: 500/500 or 200/800, etc. After the patch, up to 1000/1000 (940/940 for actual line rates).
But without hardware offload, the MT7621 is simply not enough CPU to NAT anything approaching 1 Gbps in any direction, much less 2 Gbps. It is going to top out around 500 Mbps without offload using current OpenWrt versions (a bit faster with older pre-DSA versions of OpenWrt). Still, I was happy to get ~500 Mbps with current OpenWrt versions versus ~300 Mbps with stock EdgeOS on my ER-X.
Another consideration is that an all-in-one device giving up CPU cycles to service WiFi or PPPoE will be slower than a router only configuration.
Edit: Of course, if you are already using hardware offload and a router only configuration, then I apologize for misunderstanding your question. In that case my unhelpful answer would be, sorry, I can't think of anything to help you 
Yes, with hardware offload and router only, same problem, so i'm thinking maybe the CPU is way to small.
But you are right about the older version, on OpenWRT 19 i had a very nice 1GB bandwith on the WAN, the "problem" came after the 21 update.
It's mandatory for me to use OpenWRT, so there is my two options right now : Finding a solution to making the patch working on the Cudy (maybe i'm doing something wrong), or getting back at the old firmware, but i'm concern about security and updates.
Do you really need all that bandwidth? Maybe you could downgrade your plan (save a few bucks as well)