OpenWrt Forum Archive

Topic: TP-Link Archer C7: 802.11ac slower in OpenWRT than native firmware

The content of this topic has been archived between 19 Apr 2018 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

I have an Archer C7 v2. Is OpenWRT expected to be slower than native firmware under TCP? How about in general on various routers?

Doing an iperf test between two machines behind the router -- one LAN (wired), one WLAN (wireless). The wired one runs Windows 8.1 Pro and the wireless one runs MacOSX 10.10 (Macbook Pro late 2013), using the settings below. On Windows, I used the JPerf 2.0.2 package (GUI over iperf), while on MacOSX 10.10 I used iperf from Macports (just do "port install iperf"). In all tests, the router sits at about half a meter in front of the laptop and the position is not changed, nor anything is moving in the room, while the tests are running. Channel fading is thus low and consistent. I used channel 36 and 149 with VHT80 (all other settings left on their defaults; both channels give same results, 149 allows for higher Tx power). The "-i 1" causes iperf to report speed every second.

If you wish to test yourself, make sure the wireless machine is a true 3-stream (3x3 mimo) AC1300 801.11ac, i.e. support tru 1300 Mbps PHY rate with aggregate AMPDU support (latter should be available by default) -- using phones/tablets or devices that are not 3-stream AC1300 will not reveal differences. The other machine must be wired on a gigabit port. Otherwise you won't be able to hit 800+ Mbps.


Iperf commands:

(server, Mac): iperf -s -i 1 -w 6M
(client, Win): iperf -c 192.168.1.19 -i 1 -w 6M -l 2M


TP-Link firmware TCP results (latest TP-Link firmware from 11 Sept 2014)

[ ID] Interval       Transfer     Bandwidth
[216]  0.0- 1.0 sec   102 MBytes   856 Mbits/sec
[216]  1.0- 2.0 sec   104 MBytes   872 Mbits/sec
[216]  2.0- 3.0 sec   104 MBytes   872 Mbits/sec
[216]  3.0- 4.0 sec   104 MBytes   872 Mbits/sec
[216]  4.0- 5.0 sec  96.0 MBytes   805 Mbits/sec
[216]  5.0- 6.0 sec   104 MBytes   872 Mbits/sec
[216]  6.0- 7.0 sec   104 MBytes   872 Mbits/sec
[216]  7.0- 8.0 sec   104 MBytes   872 Mbits/sec
[216]  8.0- 9.0 sec   104 MBytes   872 Mbits/sec
[216]  9.0-10.0 sec   104 MBytes   872 Mbits/sec
[216]  0.0-10.1 sec  1032 MBytes   860 Mbits/sec
Done.


OpenWRT TCP results (OpenWRT 14.07 release):

[212]  0.0- 1.0 sec  46.0 MBytes   386 Mbits/sec
[212]  1.0- 2.0 sec  64.0 MBytes   537 Mbits/sec
[212]  2.0- 3.0 sec  64.0 MBytes   537 Mbits/sec
[212]  3.0- 4.0 sec  64.0 MBytes   537 Mbits/sec
[212]  4.0- 5.0 sec  56.0 MBytes   470 Mbits/sec
[212]  5.0- 6.0 sec  64.0 MBytes   537 Mbits/sec
[212]  6.0- 7.0 sec  64.0 MBytes   537 Mbits/sec
[212]  7.0- 8.0 sec  64.0 MBytes   537 Mbits/sec
[212]  8.0- 9.0 sec  48.0 MBytes   403 Mbits/sec
[212]  9.0-10.0 sec  56.0 MBytes   470 Mbits/sec
[212]  0.0-10.1 sec   592 MBytes   491 Mbits/sec
Done.

NOTE: That was the best score I managed to record. Most of the time, the speed under OpenWRT drops to 200 Mbits/s or fluctuates between 200 and 500 Mbits/s. It is never as consistent or as high as the speed under the TP-Link firmware on when using TCP.


Using UDP instead of TCP, then both OpenWRT and TP-Link firmware yield around 800 Mbits/s.. With a UDP buffer size of 1MB, iperf settings were:

(server, Mac): iperf -s -u -i 1 -w 1M -l 4K
(client, Win): iperf -c 192.168.1.101 -i 1 -w 1M -l 4K -b 850M

[SUM]  1.0- 2.0 sec  98.5 MBytes   826 Mbits/sec
[  4]  2.0- 3.0 sec  98.5 MBytes   827 Mbits/sec   0.039 ms 1123/26350 (4.3%)
[  4]  2.0- 3.0 sec  152 datagrams received out-of-order
[  4]  3.0- 4.0 sec  98.5 MBytes   826 Mbits/sec   0.044 ms 1082/26292 (4.1%)
[  4]  3.0- 4.0 sec  182 datagrams received out-of-order
[  4]  4.0- 5.0 sec   100 MBytes   841 Mbits/sec   0.080 ms  904/26557 (3.4%)
[  4]  4.0- 5.0 sec  160 datagrams received out-of-order
[  4]  5.0- 6.0 sec  85.7 MBytes   719 Mbits/sec   0.030 ms 4103/26039 (16%)
[  4]  5.0- 6.0 sec  153 datagrams received out-of-order
[  4]  6.0- 7.0 sec   100 MBytes   841 Mbits/sec   1.580 ms  808/26478 (3.1%)
[  4]  6.0- 7.0 sec  327 datagrams received out-of-order
[  4]  7.0- 8.0 sec  88.1 MBytes   739 Mbits/sec   0.039 ms 3598/26151 (14%)
[  4]  7.0- 8.0 sec  198 datagrams received out-of-order
[  4]  8.0- 9.0 sec  85.5 MBytes   717 Mbits/sec  57.913 ms 4441/26333 (17%)
[  4]  8.0- 9.0 sec  195 datagrams received out-of-order
[  4]  0.0- 9.9 sec   944 MBytes   799 Mbits/sec   0.971 ms 21178/262767 (8.1%)
[  4]  0.0- 9.9 sec  1799 datagrams received out-of-order


Question

Obviously the router itself is capable of hitting 800+ Mbits/s. I know TCP is more demanding on the CPU than UDP, so is the lower TCP throughput in OpenWRT due to the driver used?

If not, any pointers or ideas on what to try to improve it? See below things I've already tried.

- Fresh OpenWRT was flashed then the following issued: uci set wireless.radio0.htmode=VHT80; uci set wireless.radio0.disabled=0; uci commit; wifi; ... nothing else was installed or enabled.
- I tried using both open (no auth) and WPA/WPA2.
- Also tried using channel 149 so I could use 30 dBm Tx power (channel 36 was limited to 17dBm).
- Also tried setting sysctl options net.core.rmem_max=2097152, net.core.wmem_max=2097152, net.ipv4.tcp_rmem=4096 87380 2097152 and net.ipv4.tcp_wmem=4096 87380 2097152.
- Checked the received power strength under both firmwares (under MacOSX > Wireless Diagnostics > Performance) and it was pretty much the same in both cases, around -40 dBm. Channel noise is around -95/-96 dBm. So no saturation.

Nothing I tried helped getting more throughput under TCP in OpenWRT ... any clues?

Are there any known kernel modules that take such a toll in OpenWRT? What modules are safe to disable for this simple test? (assuming nothing else is needed)

Cheers.

p.s. On wired-to-wired I hit 940+ Mbits/s without much effort on both firmwares, which is expected since only the hardware ethernet switch is used in this case.

(Last edited by mastabog on 27 Nov 2014, 04:32)

Well done on the extremely thorough job. I'd be very curious what you see with pure-wireless test. With stock, it tops out at around 220 AFAIK.

All I can add is a general impression made over the years: firmware like OpenWRT and DD-WRT very commonly slow things down. Reports of them speeding things must be very rare, since I don't remember any.

slow and buggy, if not webcam and ad-blocking on router I would not use it. Whenever I complain some arrogant writes me to build own firmware :-(

What version of OpenWRT did you use for these tests?

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

bibocc wrote:

What version of OpenWRT did you use for these tests?

As I said in my post "Using OpenWRT 14.07". I tried recent trunk snapshots, but none work, they all seem broken in many respects; the wireless driver doesn't even recognize the 5GHz adapter, so the archer-c7 trunk snapshots are pretty useless ...

drawz wrote:

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

First, the two machines were on the LAN, there's no WAN or NAT involved (but the bigger and more complex iptables tables in OpenWRT may take a toll, I don'tknow). Still, even if that were to be the reason, then wouldn't the UDP speed be lower for OpwnWRT? Right now both firmwares get the same speed on UDP. See my original post. It's just on TCP that things get much slower on OpenWRT.

(Last edited by mastabog on 1 Nov 2014, 05:09)

drawz wrote:

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

Isn't what's going on above LAN-LAN though?  I thought the problem was only WAN-LAN.
https://forum.openwrt.org/viewtopic.php … 32#p251532

rseiler wrote:
drawz wrote:

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

Isn't what's going on above LAN-LAN though?  I thought the problem was only WAN-LAN.
https://forum.openwrt.org/viewtopic.php … 32#p251532

The tests were run between two machines on the LAN behind the router, one wired, one wireless. There's no WAN involved, so no NAT either. However, I don't know how much the bigger and more complex iptables tables of OpenWRT are taking a toll ... they re clearly not a problem on UDP (both firmwares get the same throughput then). It's TCP that gets much slower on OpenWRT.

(Last edited by mastabog on 1 Nov 2014, 05:10)

rseiler wrote:
drawz wrote:

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

Isn't what's going on above LAN-LAN though?  I thought the problem was only WAN-LAN.
https://forum.openwrt.org/viewtopic.php … 32#p251532

Oops my bad. LAN-LAN shouldn't be slower though. Did you test with both clients wired? Did you test on both bands of wireless? This would help narrow the problem. Apologies if you already stated this.

drawz wrote:
rseiler wrote:
drawz wrote:

no hardware NAT acceleration in openwrt or dd-wrt. the code released by atheros is not compatible with several openwrt/dd-wrt features.

Isn't what's going on above LAN-LAN though?  I thought the problem was only WAN-LAN.
https://forum.openwrt.org/viewtopic.php … 32#p251532

Oops my bad. LAN-LAN shouldn't be slower though. Did you test with both clients wired? Did you test on both bands of wireless? This would help narrow the problem. Apologies if you already stated this.

Are you an OpenWRT developer? I did state that on wired neither firmware has a problem and they hit 940+ Mbps. I'm willing to provide more info but it would also help if you read my original report (I don't mean to be an ass by it, but I did provide detail there which answer both your posts so far).

Testing on 2.4 GHz would be rather pointless for two reasons:
(i) the whole 2.4 GHz spectrum is very crowded here where I live and the results would be skewed due to too much collision avoidance
(ii) as I already showed, OpenWRT already achieves 450 Mbits/s on 5GHz at the application level, i.e. 500-600 Mbps at the PHY level. Given that the 2.4GHz band on this router is limited to 450 Mbps PHY (about 350-400 Mbps at application level with large AMPDU), then that would be the bottleneck for both firmwares, both would hit it easily if channels were clean.

So far I think the problem is OpenWRT's wifi driver. If it was due to kernel modules or the more complex iptables tables hogging the CPU then the problem would have shown in the UDP or wired tests as well, but there it doesn't. Monitoring the CPU usage with "top" shows max 6-8% CPU load when doing the TCP iperf test.

Are there any wifi driver parameters that I could try to tweak with? Anyone has any other ideas?

(Last edited by mastabog on 1 Nov 2014, 17:01)

mastabog wrote:
drawz wrote:
rseiler wrote:

Isn't what's going on above LAN-LAN though?  I thought the problem was only WAN-LAN.
https://forum.openwrt.org/viewtopic.php … 32#p251532

Oops my bad. LAN-LAN shouldn't be slower though. Did you test with both clients wired? Did you test on both bands of wireless? This would help narrow the problem. Apologies if you already stated this.

Are you an OpenWRT developer? I did state that on wired neither firmware has a problem and they hit 940+ Mbps. I'm willing to provide more info but it would also help if you read my original report (I don't mean to be an ass by it, but I did provide detail there which answer both your posts so far).

Testing on 2.4 GHz would be rather pointless for two reasons:
(i) the whole 2.4 GHz spectrum is very crowded here where I live and the results would be skewed due to too much collision avoidance
(ii) as I already showed, OpenWRT already achieves 450 Mbits/s on 5GHz at the application level, i.e. 500-600 Mbps at the PHY level. Given that the 2.4GHz band on this router is limited to 450 Mbps PHY (about 350-400 Mbps at application level with large AMPDU), then that would be the bottleneck for both firmwares, both would hit it easily if channels were clean.

So far I think the problem is OpenWRT's wifi driver. If it was due to kernel modules or the more complex iptables tables hogging the CPU then the problem would have shown in the UDP or wired tests as well, but there it doesn't. Monitoring the CPU usage with "top" shows max 6-8% CPU load when doing the TCP iperf test.

Are there any wifi driver parameters that I could try to tweak with? Anyone has any other ideas?

Not a developer, so I can't really help much, just brainstorming with you. But I asked about 2.4 Ghz because on this router that uses the Ath9k driver while 5 GHz uses the Ath10k driver. Ath10k is not as mature at this point. I also thought you should test wired to take the wifi driver out of the equation, but it sounds like you're suspicious of wifi and want to focus on fixing that.

I  have 3 of these routers and I've had problems with 5Ghz too.   I find certain TCP connections get dropped or blocked on 5Ghz but are okay on 2.4Ghz.   I've upgraded my WIFI clients to the latest Intel wireless drivers too.

I compiled a new version of 14.07 r42943 to test on one of them (there is a new ath10k firmware version in r42943) but there's no improvement on 5Ghz.  My two others are running 14.07 r42625.   

I'm going to do some more testing using other 5Ghz clients but I agree that ath10k looks pretty immature.
I might also try Chaos Calmer as there is at least one further patch to ath10k that might make a difference.

dem wrote:

I'm going to do some more testing using other 5Ghz clients but I agree that ath10k looks pretty immature.
I might also try Chaos Calmer as there is at least one further patch to ath10k that might make a difference.

See my post above about that: all recent trunk spanshops I tried are broken (don't even see the 5GHz phy, plus other broken things/packages). I'd be surprised if you managed to compile an actual working binary, but do please let us know here, and also please share it if it's actually any better.

drawz wrote:

Not a developer, so I can't really help much, just brainstorming with you. But I asked about 2.4 Ghz because on this router that uses the Ath9k driver while 5 GHz uses the Ath10k driver. Ath10k is not as mature at this point. I also thought you should test wired to take the wifi driver out of the equation, but it sounds like you're suspicious of wifi and want to focus on fixing that.

I did test wired (please see above, or the 1st post). As I said, 2.4 GHz would not be a problem since it's already exceeding the max 2.4 speed and is not of interest anyway. I want it to hit the 800-900 Mbps on 11ac like it does on the native firmware.

(Last edited by mastabog on 3 Nov 2014, 07:23)

You are getting 800-900Mbps on LAN <--> 11ac ?? That must be some kind of record, no? I've read lots of reviews of this router and the max throughput I have seen in benchmarks are 400Mbps:

http://www.smallnetbuilder.com/wireless … mp;start=2

So how is it you are getting double the performance? As far as I know there are very few routers that can actually achieve that kind of speed on wireless.

You're actually besting the speed of two paired Asus RT-AC87U routers. No other routers on the market can achieve the speeds you are getting from a router to a laptop. So very curious how you can get results like that.

http://www.pcworld.com/article/2597549/ … -fast.html

(Last edited by arokh on 3 Nov 2014, 09:21)

arokh
LAN<->WLAN 800-1000 Mbps
WLAN<->WLAN 400-600 Mbps

with free frequency band

(Last edited by trismo on 3 Nov 2014, 09:39)

I don't have ac hardware myself so I can't confirm this, but your speeds seem impossible considering you are beating the fastest router on the market. See the tests above, how is that possible?

arokh wrote:

You are getting 800-900Mbps on LAN <--> 11ac ?? That must be some kind of record, no? I've read lots of reviews of this router and the max throughput I have seen in benchmarks are 400Mbps:

http://www.smallnetbuilder.com/wireless … mp;start=2

So how is it you are getting double the performance? As far as I know there are very few routers that can actually achieve that kind of speed on wireless.

You're actually besting the speed of two paired Asus RT-AC87U routers. No other routers on the market can achieve the speeds you are getting from a router to a laptop. So very curious how you can get results like that.

http://www.pcworld.com/article/2597549/ … -fast.html

arokh wrote:

I don't have ac hardware myself so I can't confirm this, but your speeds seem impossible considering you are beating the fastest router on the market. See the tests above, how is that possible?

I laid out all the details in my first post which clearly answers all your questions and suspicions. You could just read it. If still in doubt, you could buy it and repeat the steps and setup from the 1st post. Otherwise I don't quite know what to make of your posts (other than you like Asus).

(Last edited by mastabog on 3 Nov 2014, 22:35)

I'm just curious more than anything, was just wondering if those speeds are correct or perhaps the test is at fault somehow.

How is the cpu load when you are testing in openwrt btw?

arokh wrote:

I'm just curious more than anything, was just wondering if those speeds are correct or perhaps the test is at fault somehow.

How is the cpu load when you are testing in openwrt btw?

How can the test be at fault? Honestly, it's all in the 1st post. Feel free to read the details and replicate it. Everything is correct (I copy-pasted the iperf results). It's not just iperf; using wget to fetch a large file from the Win PC gets the same speed. I also reported the CPU % in a post above, around 6%, which is expected (it's not doing any NAT).

(Last edited by mastabog on 4 Nov 2014, 20:40)

@arokh You might be confusing 2.4Ghz 802.11n with 5Ghz 802.11ac specification.

http://en.wikipedia.org/wiki/IEEE_802.1 … _and_speed

The Archer C7 has two radios - 2.4Ghz and 5Ghz
It is actually advertised as AC1750 which is supposed to be 1300 Mbit/s.  Of course we will never see those speeds in practice.

Not at all, I'm aware of 5GHz theorerical speeds. Like I said, other benchmarks does not even come close to gigabit speeds have a look around. Was just looking for an explanation about that, perhaps reviewers aren't using clients capable of utilizing several streams, I don't know.

arokh wrote:

Not at all, I'm aware of 5GHz theorerical speeds. Like I said, other benchmarks does not even come close to gigabit speeds have a look around. Was just looking for an explanation about that, perhaps reviewers aren't using clients capable of utilizing several streams, I don't know.

I don't wish to sound cross, but this is getting odd and very off-topic. The results are correct and other 11ac routers get the same speeds. Even the link you provided shows 850+ Mbps 11ac speeds -- look at the first graph.

Let's please get back to the actual topic, i.e. the fact that OpenWRT gets consistently lower speeds than the native firmware.

(Last edited by mastabog on 6 Nov 2014, 23:25)

Is anybody actively working on this? I just got an Archer C7 this week and am dying to get off the stock firmware (I need a DNS server, for example).

I am pleased with the stock firmware and don't want to lose any performance going with OpenWRT.

Okay so I've compiled a new Chaos Calmer (r43186) for the Archer C7 and I actually need to correct a statement I made earlier.   This new CC version has the new ATH10K firmware version 3 whereas my later BB build has the same firmware version 2 as my earlier BB (r42943 and r42625 respectively).

I ran out of time today to test the 5Ghz as I decided to run your iperf tests on BB before hand to see if there was any difference between BB and CC with the new firmware.

Unfortunately I found I was getting very poor 5Ghz wireless speeds so I decided to installed iperf on the BB C7 router and run the same tests between the router and a server but this time solely via Ethernet. 
This time the maximum TCP speeds I got was just over 200Mbits/sec!?  This is supposed to be on Gigabit Ethernet.

I ran "swconfig dev switch0 show" to check that the C7 was connected via Gigabit.  Indeed it was.  I thought maybe the old Ethernet cabling in the building wasn't rated CAT5e or higher so I ran some tests between servers and got over 1.6 Gigabit/sec and finally between a Windows 7 desktop and a server (on a long cable run) and got consistently over 870Mbits/sec

I thought maybe iperf was maxing out the CPU on the C7 and hence that was causing the slow down but "top" confirmed iperf was using less than 70% CPU and it had plenty spare idle.    I ran the same iperf tests on the older BB version and still got just over 200Mbit/sec.

I just wonder whether the slow 200Mbit/sec speed is still down to the C7 resources.  I will see if I can do some profiling on Openwrt to see why iperf delivers such poor Ethernet speeds on the C7.    Maybe I need to adjust some settings with sysctl to improve TCP speeds.

@Mastabog  Any chance you'd be able to run the same Ethernet tests on you C7 to see what you get?
I'm keen to test the new CC build's 5Ghz speeds next week but I want to be sure the bottleneck isn't going to be on the Ethernet first.

Has anyone else done Ethernet benchmarking on Openwrt using iPerf?

You need to be more specific.
There are different types of Ethernet Test.
If you put the client and the server on the same network where there is no translation of IP Address then you are testing LAN to LAN throughput
If you put the client and the server on different network where there is translation of IP Address then you are testing LAN to WAN throughput.