@alphasparc   If you read the whole topic from start to finish you will understand the context of the tests and the exact iperf commands used.   They are clearly LAN based tests with no NAT.

I'm now back on the native firmware, but I did run wired tests with iperf on the router. It's expected to be this slow. The CPU in the router can't handle the load efficiently (50%+ is actually a lot) -- when you run iperf in the router, a lot now happens at the application level, rather than in hardware (switch). You need to hook two more powerful machines with Gigabit ethernet to the router and do the iperf test on those.

I even did a 5GHz test with iperf on the router just to see how bad it is, and it was abysmal.

Is it it understood that you should only run iperf on 2 separate machines from the router to simulate the actual network?

Okay thanks Mastabog.   I'll give the C7 a quick test before I test the 5Ghz with CC although presumably it should be similar to all my other non router iperf test speeds as it will just be using the Gigabit switch.

Indeed. I already did the wired-to-wired tests and got 940+ Mbps (as reported in my 1st post). Looking forward to your wired-to-11ac tests on the new OpenWRT compiled formware with the new ath10k driver -- however, shouldn't the new driver be already in the latest trunk snapshots? It would save you the compilation time... that is if they're actually working (the trunk snapshots I tried were not even recognizing the 5GHz interface, maybe the newer snapshots are better)

(Last edited by mastabog on 9 Nov 2014, 08:15)

Yes the trunk nightly builds should be up to date.   I normally build BB because the images are often over a month old and I like to have the latest bug fixes and include some other packages and configuration within my own images to speed configuration and installation.

The trunk may not have worked on your C7 with 5Ghz due to the missing kmod-ath10k support for ath10k which is not included in the image.  I found once installed the 5Ghz radio works but I now include the kernel support in my images.

I've also found the original wireless card I tested 5Ghz with was only 5Ghz  802.11n not 802.11ac so I will test it with a different card.

Sure, just make sure you will use a 11ac card with 3 spatial streams to hit 1300 Mbps PHY rate on 80 MHz channels with short guard interval (2 streams only get you 867Mbps).

I have been following this thread since I am also having some issues with a C7. By dem's suggestion I installed CC snapshot and I see some improvement in stability. I know this thread is about throughput but I wanted to share a difference that I noted between CC and BB using these tests.

When testing for UDP performance, I noticed that using BB you get higher throughput reported by iperf (~800 Mbps) but a lot of out of order packets. On CC there are barely no out of order packets (there are still lost packets), and the reported throughput by the server is lower (~500Mbps)

@elventear: Wait, are you saying that there is a CC snapshot which has a working ath10k driver (5GHz radio is working)? All the ones I tried a week ago were missing the ath10k driver and the 5GHz is not working as a result.

The out of order issue can happen due to several problems completely external to the firmware/driver (I sometimes had them, sometimes not while using the same firmware and even same login session!). I wouldn't be 100% certain that the latest CC is more stable than BB, but it is possible.

This morning I did sys upgrade from BB to CC snapshot, using this image:

https://downloads.openwrt.org/snapshots … pgrade.bin

And I installed the ath10k kernel module and I am running 802.11ac. Right out of the bat I have noticed that I have much better SNR on my 802.11ac client and it has been much more stable. I haven't done any in-depth tests because I don't really have time, but I am already seeing a big difference between CC and BB.

Regarding the out of order packets with UDP; as I said, I just did a few tests, but for me I had around 150 out of order packets in each phase of the iperf tests with BB; and this happened being a few centimeters away from the AP during my tests for every single test. After upgrading to CC, I tried the same test and only get 1 out of order packet for every test being a couple of meters away. I do think they are related to the change of firmware. But I can be wrong.

I have not tried the tests with the native firmware, and I don't think I will, I just want a stable and decent throughput (plus the other OpenWRT configurability), but I don't think CC will match what you have seen with the native firmware. You should still try the CC image and see if it works better for you.

That may be your issue right there: a few centimeters away can cause signal saturation (the PHY amplifier and equalization is thrown off) and then the PHY drops MPDUs. Using UDP (which does not have ACKs) you ent up with dropped or out of order packets. That, or maybe the new driver and stack in CC are better at queuing packets from the application level, given you are forcing a higher app rate than the driver can handle.

But you did make me curious. I'll give a CC snapshot another try and install the ath10k module manually (is there a pkg for that or did you compile it?).

(Last edited by mastabog on 11 Nov 2014, 22:07)

> opkg update
> opkg install kmod-ath10k

Worked for me

This is a bit off-topic to the post, but since there are Archer C7 V2 users here it seems like a good place to ask:

I've seen quite a few posts complaining about issues with the ath10k and 5 GHz band, some saying that they get atrocious throughput on 5ghz (~6mbits).  From some discussion on this thread it sounds like the performance is actually not miserable, but may be reduced (on the order of half) from stock firmware.  I'm not too concerned about this scale of reduction, but I'm wondering whether otherwise the performance is pretty decent in terms of reliability of connections and stability?

The stock firmware has been OK (wireless stopped routing yesterday requiring a reboot, but hard connections were fine), but I'd like a bit more freedom to tweak things and experiment (having runing dd-wrt, various Tomato forks and OpenWRT once or twice), but the main thing I'd like is something that works reliably and doesn't have an appreciable loss in range.

Is the trunk currently a good option for this?  Or should I stick with stock for now?

I would say that if you want to use OpenWRT, then CC snapshot is the way to go. But there aren't any guarantees.

I tested both and quite a few packages are broken in the CC snapshot. In terms of reliability, I didn't notice differencies but I only tested 2.4 GHz on CC. The BB release was pretty reliable on both 2.4 GHz and 5 GHz, with the performance you see reported in the 1st post. You could go for that.

This thread caught my attention so I have had a play myself. I was more interested in WAN<->LAN traffic as I only use wireless for convenience. Using iperf I first tested via LAN<->LAN  to check cables connection and got 934 Mbits/sec so that checks out.

Test bed of LAN<->WAN is the same wiring from 10.10.x.x to a 192.168.x.x range.
With TP-Link Archer_C7_V2_V3_140929 FW:
Test 1: 899 Mbits/sec
Test 2: 911 Mbits/sec
Test 3: 930 Mbits/sec

OpenWRT  Barrier Breaker 14.07 ar71xx/generic:
Test 1: 325 Mbits/sec
Test 2: 323 Mbits/sec
Test 3: 325 Mbits/sec

Top shows that there was 0% idle (98%sirq) so I assume that the factory firmware is using hardware acceleration for routing that OpenWRT cannot / does not take advantage of?

(Last edited by anotherUser on 20 Nov 2014, 02:35)

Yes, there is HW NAT used by TP-Link, that is not available in openwrt for a variety of reasons. This can be disabled and it would be interesting to retest with it off in stock firmware.

That sounds reasonable, results were:

With TP-Link Archer_C7_V2_V3_140929 and hardware NAT disabled:
Test 1: 317 Mbits/sec
Test 1: 318 Mbits/sec
Test 1: 318 Mbits/sec

Slight edge to OpenWRT without HW acceleration.

What days snapshot you are running, where can i download it?

(Last edited by PJK on 22 Nov 2014, 12:30)

same here is there a newer direct version out for the v2 then 14.07 bb?? i do not have to build (new to open wrt still learning)

you can download a nightly snapshot from downloads.openwrt.org but please keep in mind that Luci (web UI) is not included in these builds and that you can only install certain packages from the same build version. So in other words, download, flash, and install all the packages you need on the same day to avoid problems with version conflicts. There are instructions in the wiki for installing Luci from the command line.

Read these two pages before proceeding:
http://wiki.openwrt.org/doc/howto/snapshots
http://wiki.openwrt.org/about/latest

The wiki is a little out of date (AA is no longer the current stable version), but you can get the gist of it.

(Last edited by drawz on 25 Nov 2014, 00:17)

@TheDrizzle Could you please create a different topic for that? This one is specific to a particular (and different) issue. Good luck with learning about OpenWRT though, you won't regret it.

@dem and @elventear: any new results with trunk CC or trunk BB+new driver?

(Last edited by mastabog on 25 Nov 2014, 02:33)

Hi @mastabog

I've now tested UDP and TCP iperf with a C7 Version 2 with stock TP Link firmware (version 3.13.34)  ,  BB 14.07, and CC (r43186)

I have not had much spare time lately so I only tested it with a Nexus 5 which has 802.11ac although I suspect only one of the lower speed specifications   AC600?

Situated right next to the C7 I got physical link speed on the Nexus 5 of 433 Mbps  with both factory and CC.  However with BB I only ever got 150Mbps!? link speed on 5 Ghz so I didn't even bother testing it with iPerf

Here are my results using mastabog's iPerf TCP and UDP settings.   Repeated tests revealed very little difference in average speeds.

UDP test

TP-Link factory

[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[140]  0.0- 1.0 sec  32484 KBytes  266109 Kbits/sec  0.127 ms  190/ 8311 (2.3%)
[140]  0.0- 1.0 sec  3 datagrams received out-of-order
[140]  1.0- 2.0 sec  32144 KBytes  263324 Kbits/sec  0.127 ms    0/ 8036 (0%)
[140]  2.0- 3.0 sec  33976 KBytes  278331 Kbits/sec  0.147 ms    0/ 8494 (0%)
[140]  3.0- 4.0 sec  33124 KBytes  271352 Kbits/sec  0.119 ms    0/ 8281 (0%)
[140]  4.0- 5.0 sec  33492 KBytes  274366 Kbits/sec  0.136 ms    0/ 8373 (0%)
[140]  5.0- 6.0 sec  33456 KBytes  274072 Kbits/sec  0.108 ms    0/ 8364 (0%)
[140]  6.0- 7.0 sec  33444 KBytes  273973 Kbits/sec  0.162 ms    0/ 8361 (0%)
[140]  7.0- 8.0 sec  33328 KBytes  273023 Kbits/sec  0.908 ms    0/ 8332 (0%)
[140]  8.0- 9.0 sec  32868 KBytes  269255 Kbits/sec  0.144 ms    0/ 8217 (0%)
[140]  9.0-10.0 sec  32824 KBytes  268894 Kbits/sec  0.159 ms    0/ 8206 (0%)
[140]  0.0-10.0 sec  331864 KBytes  271142 Kbits/sec  0.224 ms  189/83021 (0.23$
[140]  0.0-10.0 sec  4 datagrams received out-of-order

Chaos Calmer

[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[144]  0.0- 1.0 sec  34248 KBytes  280560 Kbits/sec  0.164 ms  152/ 8714 (1.7%)
[144]  1.0- 2.0 sec  32940 KBytes  269844 Kbits/sec  0.262 ms    0/ 8235 (0%)
[144]  2.0- 3.0 sec  33104 KBytes  271188 Kbits/sec  0.148 ms    0/ 8276 (0%)
[144]  3.0- 4.0 sec  33048 KBytes  270729 Kbits/sec  0.159 ms    0/ 8262 (0%)
[144]  4.0- 5.0 sec  32468 KBytes  265978 Kbits/sec  0.120 ms    0/ 8117 (0%)
[144]  5.0- 6.0 sec  34128 KBytes  279577 Kbits/sec  0.125 ms    0/ 8532 (0%)
[144]  6.0- 7.0 sec  33400 KBytes  273613 Kbits/sec  0.146 ms    0/ 8350 (0%)
[144]  7.0- 8.0 sec  33400 KBytes  273613 Kbits/sec  0.125 ms    0/ 8350 (0%)
[144]  8.0- 9.0 sec  33932 KBytes  277971 Kbits/sec  0.295 ms    0/ 8483 (0%)
[144]  9.0-10.0 sec  34408 KBytes  281870 Kbits/sec  0.814 ms    0/ 8602 (0%)
[144]  0.0-10.0 sec  335536 KBytes  274192 Kbits/sec  0.249 ms  151/84028 (0.18$
[144]  0.0-10.0 sec  1 datagrams received out-of-order

TCP test

TP-Link factory

[ ID] Interval       Transfer     Bandwidth
[264]  0.0- 1.0 sec  27830 KBytes  227985 Kbits/sec
[264]  1.0- 2.0 sec  30851 KBytes  252730 Kbits/sec
[264]  2.0- 3.0 sec  33485 KBytes  274306 Kbits/sec
[264]  3.0- 4.0 sec  31931 KBytes  261579 Kbits/sec
[264]  4.0- 5.0 sec  30266 KBytes  247936 Kbits/sec
[264]  5.0- 6.0 sec  27890 KBytes  228471 Kbits/sec
[264]  6.0- 7.0 sec  28062 KBytes  229884 Kbits/sec
[264]  7.0- 8.0 sec  27851 KBytes  228158 Kbits/sec
[264]  8.0- 9.0 sec  28652 KBytes  234718 Kbits/sec
[264]  9.0-10.0 sec  28646 KBytes  234669 Kbits/sec
[264]  0.0-10.0 sec  296960 KBytes  242552 Kbits/sec

Chaos Calmer

[ ID] Interval       Transfer     Bandwidth
[268]  0.0- 1.0 sec  28048 KBytes  229769 Kbits/sec
[268]  1.0- 2.0 sec  29517 KBytes  241803 Kbits/sec
[268]  2.0- 3.0 sec  30351 KBytes  248639 Kbits/sec
[268]  3.0- 4.0 sec  28170 KBytes  230765 Kbits/sec
[268]  4.0- 5.0 sec  28891 KBytes  236678 Kbits/sec
[268]  5.0- 6.0 sec  29644 KBytes  242845 Kbits/sec
[268]  6.0- 7.0 sec  28821 KBytes  236103 Kbits/sec
[268]  7.0- 8.0 sec  29470 KBytes  241422 Kbits/sec
[268]  8.0- 9.0 sec  30179 KBytes  247226 Kbits/sec
[268]  9.0-10.0 sec  28485 KBytes  233348 Kbits/sec
[268]  0.0-10.0 sec  292864 KBytes  239130 Kbits/sec

We see virtually no difference in performance between Factory and CC for both UDP and TCP.  In fact after repeated tests Factory and CC both beat each other marginally which we can assume is just down to expected variability.

One thing to note though was that CC was more consistent in TCP speeds between each 1 second interval.

Also I found that there seems to be a bug in CC where 5 Ghz wireless does not work unless 2.4Ghz is enabled too.  Obviously ath10k-kmod needs installing too.

(Last edited by dem on 27 Nov 2014, 00:58)

@dem, I already showed in my 1st post that OpenWRT can reach 400+ Mbps using the official BB release. Your nexus 5 limits you below 250 Mbps.

The idea of this thread was to understand why and how to make OpenWRT reach 800+ Mbps on 11ac like it does on the tp-link firmware. Currently it's stuck somewhere around 500 Mbps.

To anyone who wishes to test: you must use an 801.11ac machine with true 3-stream (3x3 mimo) AC1300 (max PHY rate 1300 Mbps), with the other machine on wired ethernet. I used a Macbook Pro late 2013 for the wireless. Tests using phones or devices that are not 3-stream AC1300 will not reveal speed differences between tp-link and openwrt firmwares, i.e. doesn't help the scope of this thread.

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

@Mastabog Have you done iPerf testing with CC yet yourself?

I thought it was interesting that it demonstrated that there was no difference between factory and CC yet there was a significant difference between factory and BB.

The trouble with 3 x 3 mimo is that you need 3 antennas.   If you have laptops it is hardly feasible to retro fit an existing laptop with a 3 antenna configuration as most will traditionally have only 2 antennas so that really only leaves a large USB 3.0 device which is not great on a laptop .    Most people who already have desktops on gigabit Ethernet are not going to buy a 3 x 3 mimo 802.11ac wireless adapter either.