WAX206 Slow Upload Speeds

I'm currently using the May 25 2023 snapshot on my Netgear WAX206, I have noticed that the upload consistently suffers by about 50% from the factory stock firmware. I have verified MTU values are the same (1500) and tested MSS Clamping on/off, it didn't make a difference. Every time I'm on OpenWRT upload suffers by about 50% and when I fail back it goes back to normal. Any advice on what else to try would be appreciated.

Top image shows speeds on openwrt-mediatek-mt7622-netgear_wax206-squashfs-factory
Bottom image shows speeds on Netgear WAX206_Firmware_V1.0.4.0.img

Did you perform the speed tests connected by wire or WiFi?

1 Like

Both tests were done via cat5; I forgot to mention my ISP is Verizon Fios. I even restarted my ONT.

Just now I re-installed the snapshot -> restarted the ONT -> rebooted the router and tested again. Same wired config, same computer, and same browser. No physical difference, yet there's still a considerable performance hit on the upload side.

So much for my thinking it may be a wifi hardware offload difference between download and upload.

This is a bit puzzling - seems like the MT7622 in the WAX206 should be plenty fast enough to route Gbps in either direction if you're not running CAKE SQM/QoS, OpenVPN or such.

You could try experimenting singly and with combinations of checking (enabling) software offload in the luci>network>firewall menu, packet steering in the luci>network>interfaces global network options tab and installing and enabling irqbalance (by editing the file /etc/config/irqbalance). Those are all long shots though, especially the latter two since the WAX206 is only a dual core CPU. Still, won't know til you try (if you have not already).

It might also be enlightening to install and run htop in a side terminal window to see what your CPU load is doing during the speed test. Enable the option to show CPU frequency too for good measure.

Sorry, but I don't have any other ideas. It's not uncommon for OpenWrt to be slower than OEM firmware on some targets due to lacking proprietary hardware drivers. I've experienced OpenWrt being faster than OEM too, but that is less common.

I have to report some very mixed findings. Sofware offloading by itself did very little, however adding hardware flow offloading initially seemed to solve the problem; that is until I decided to test with various providers. I found that some worked well on the upload, and some did not work at all. Shantel Service company and Verizon worked just fine, I tried i3d.net (and a few others) again and download was fine, but upload failed every time. For giggles I tried to load up their page and it would not load until I disabled the hardware flow offloading. Additionally, I enabled packet steering and installed and enabled irqbalance both of those settings had little effect. I took a screenshot of the cpu under download pressure (top) and under upload pressure (bottom), you can see upload takes even less cpu than download. :person_shrugging:

I'm thinking I may have to slowly configure and save the openwrt side as much as I can until in hopes that there will be a fix, but I will probably have to revert OEM for everday use until then.

Any recommendations are most welcome, and thanks for your input.


I personally don't see anything wrong - now that offloading is enabled. Different servers should be expected to give differing results.

1 Like

The problem is not difference between testing sites. The problem is upload speed from the SAME testing sites is different in OEM and OPENWRT; 40-50% worse. Additionally, when the sw/hw offloading is enabled some sites work correctly some do not load at all because I cannot UPLOAD responses to them as you see in the failed UPLOAD test there is some weird SOCKET error when it's enabled and tested on those sites.

With HW offloading on, for example, I can't load id3.net AT ALL, with it off it works fine, surely you can see how that's a PROBLEM. Sorry if something being misunderstood. The problem is very glaring to me, OEM upload should not be 40-50% better on the SAME testing site, and offloading which is currently experimental, does not seem to work for every site and actively BREAKS some sites on my WAX206.

I tried OpenWrt SNAPSHOT, r23104-ef98dc3b3e today and after enabling sw/hd offloading, it seemed to resolve the problem. Thanks for your help.

3 Likes

I am on the same release for my wax206, but i can not comment on your upload issues as my FTTP connection is 1000/115 here in the UK.

I have the exact same issue as you, but I am on r23147.
Enabling sw/hd offloading didnt seemed to help. Would you mind sharing your whole current config?

Is your issue on wired or wireless network?

you could install a local iperf3 server and test your upload and download speed locally:

opkg update
opkg install iperf3
iperf3 -s

Then test from a Linux machine with iperf3 client: Best practices and tools for measuring wifi performance

or with iperf3 binary apps:

A fast local wi-fi connection helps always and not only to reach your full ISP uplink speed. The shorter your wireless channel is needed and used for transmission, the better. Higher speeds also help when your wi-fi spectrum is crowded by other networks and other applications.

Wireless only. Wired works fine.

I am still experiencing that issue on wireless on the 5GHz bands. I'm working on collecting data which @odrt is helping me with. See this thread: WAX206 Wireless AX or AC Upload Speed Disparity - Installing and Using OpenWrt - OpenWrt Forum

1 Like

I'm not likely to see anything though, am I really?

Most wifi 6 clients are 2x2 mimo, so will sync at 1200, but seeing as wifi by nature is half duplex, anything around 600 throughput is fine for these devices.

Wired I see the full performance of my line, the wax206 definitely performs better than my Belkin RT1800 over 5ghz.

To answer your initial question: with local iperf3 tests you will see if you are affected by wifi speed issues on your Netgear WAX206 with your OpenWrt image.

iperf3 -s -D && iperf3 -c 127.0.0.1
Connecting to host 127.0.0.1, port 5201
[  5] local 127.0.0.1 port 47812 connected to 127.0.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   698 MBytes  5.85 Gbits/sec    0   1.44 MBytes
[  5]   1.00-2.00   sec   674 MBytes  5.64 Gbits/sec    0   1.44 MBytes
[  5]   2.00-3.00   sec   772 MBytes  6.49 Gbits/sec    0   1.44 MBytes
[  5]   3.00-4.00   sec   726 MBytes  6.08 Gbits/sec    0   1.44 MBytes
[  5]   4.00-5.00   sec   680 MBytes  5.71 Gbits/sec    0   1.44 MBytes
[  5]   5.00-6.00   sec   735 MBytes  6.17 Gbits/sec    0   1.44 MBytes
[  5]   6.00-7.00   sec   661 MBytes  5.54 Gbits/sec    0   1.44 MBytes
[  5]   7.00-8.00   sec   639 MBytes  5.36 Gbits/sec    0   1.44 MBytes
[  5]   8.00-9.00   sec   632 MBytes  5.31 Gbits/sec    0   1.50 MBytes
[  5]   9.00-10.00  sec   636 MBytes  5.34 Gbits/sec    0   1.50 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  6.69 GBytes  5.75 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  6.69 GBytes  5.74 Gbits/sec                  receiver

iperf Done.

running OpenWrt SNAPSHOT, r23238-abcb30d36c, I do not see any issues.

The iperf3 client should run on a wifi station, not on localhost on the router. The test above only tests localhost memory bandwidth and SoC performance.

iperf3 -c <ip-address of your iperf3 server> -P 4 -t 60 -i 10

Iperf3 clients could run on a smartphone, laptop, desktop PC or tablet.

2 Likes

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