Very slow speed using OpenWrt

I don't want to spend more time to find ways to measure better (couldn't find a way to make speedtest run for a longer time with a larger size to see more "sustained" numbers), but these are several speedtest.net runs with an Archer A7 v5, 22.03.0 .

It's probably the worst time to test speeds, Friday 6:30 PM, and even then not bad.

After the first 3 tests I opened the web interface to try to see the CPU, and the 5-minute utilization was something like 40%, which I think is pretty close to "idle." The second 3 tests I kept the LUCI interface open, but it's so bad that just on idle it's running about 70% CPU just to show the realtime graphs, and it jumps up and down by ~20% on its own just looking at it, so it's kind of worthless to try to see anything.

But running these tests seems to have little to no impact on the CPU at all, which makes sense because after the first packet, they're probably all being directly sent to the same IP from the same source without inspection which is my understanding of what flow control does.

I've had sustained ~500MBps downloads over periods of 10+ minutes downloading files with multi-segment downloads.

wait, DD-WRT is still a thing? I can't even imagine....

2 Likes

You will get a very good speed if you use

  • openwrt 19.07.10
  • turn on Software flow offloading
  • do not use QoS (by default not using)

21.02.3 is having a software flow offloading bug so not suggest to use
22.03.0 is just the first release of 22.03 personally i will not try it if i don't have time to fix issues.

Is this valid for most/all Atheros/Qualcomm SOCs, or is it specific to archer c7 (series) ? Any reference to the bug ?

It's common to all targets, a compatibility issue with OpenWrt's custom iptables based flow-offloading setup (used by fw3) in combination with newer kernels (introduced somewhere between v4.14 and v5.4). Thanks to fw4, 22.03.x now doesn't use iptables anymore - and mainline's nftables flow-offloading implementation was never affected (fw3+iptables+flow-offloading remains unfixed).

I practically never include fw3, only my custom set of iptables rules for firewall, when building custom image.
So, does a "LINUX-native"
iptables -w -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
work on 21.02.3, as expected ?
Or, in other words, in case "firewall" is NOT included in .config when building image for 21.02.03, AND iptables rule from above is used in running image, will it work as expected ?

The problems are the custom iptables flow-offloading modules, not fw3 itself (fw3 only prevented using nftables before 22.03).

I haven't seen anyone comment on it yet, but I would add that nftables used by fw4 had a design goal of efficiency, and that really shows. I benched one of the official 22.03-rc6 builds on my linksys_ea3500 and it just about doubled the packet performance. With softOffloading enabled I was able to get up to 500mbs NAT with the stock firewall config, whereas with previous versions it topped out at just over 200. I believe this to be strictly an improvement in nftables efficiency, so should hold true across all arches. HW flow offloading is probably not going to be affected, tho.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.