@dem As I reported above and also in the 1st post, I hit 500+ Mbps on BB, so something must have been wrong with your BB setup (correct hw version file? wifi settings?)

Yes, I did test CC too, a couple of weeks ago and it performed the same as BB. There is a major difference between native fw and CC. You didn't see a difference because you used a crippled phone as a client which caps you at 250 Mbps -- any AC router hits 250 Mbps on any firmware. It's misleading state that there is no difference between firmwares when you can't push it to the capacity of the hardware.

On 3-stream AC1300 devices: plenty of laptops are 3-stream. The 3 antennas don't have to be external. For example, all Macbook Pros from 2013 onward (including early 2013) are 3-stream AC1300. You're not obliged to own a 3-stream AC1300 device, but using a crippled device to run the tests in 1st post is out of the scope of this thread and gives misleading results ... just like yours show that CC is just as fast/stable as the native fw, which is false.

(Last edited by mastabog on 27 Nov 2014, 19:58)

Followup to my post above, I just re-tested CC from today's trunk. Same conditions and setup as the 1st post.

CC trunk 20141127, TCP test: Hits 537 Mbps, but pretty erratic overall, more erratic than BB (see my 1st post), averaging at 293 Mbps.

[ ID] Interval       Transfer     Bandwidth
[192]  0.0- 1.0 sec  6.00 MBytes  50.3 Mbits/sec
[192]  1.0- 2.0 sec  32.0 MBytes   268 Mbits/sec
[192]  2.0- 3.0 sec  48.0 MBytes   403 Mbits/sec
[192]  3.0- 4.0 sec  56.0 MBytes   470 Mbits/sec
[192]  4.0- 5.0 sec  64.0 MBytes   537 Mbits/sec
[192]  5.0- 6.0 sec  64.0 MBytes   537 Mbits/sec
[192]  6.0- 7.0 sec  16.0 MBytes   134 Mbits/sec
[192]  7.0- 8.0 sec  16.0 MBytes   134 Mbits/sec
[192]  8.0- 9.0 sec  8.00 MBytes  67.1 Mbits/sec
[192]  9.0-10.0 sec  40.0 MBytes   336 Mbits/sec
[192]  0.0-10.1 sec   352 MBytes   293 Mbits/sec
Done.

Tp-link firmware re-tested today, TCP test: Dead stable near 850 Mbps ... quite impressive, frustrating!

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

Also, now I captured CPU usage with htop on OpenWRT. It's at 100% ... that's definitely the bottleneck. Could a dev perhaps figure out why this happens? I only installed kmod-ath10k after flashing the CC snapshot, nothing else, so this is as bare and light as it can get. Here's a htop snapshot on the router during one iperf tcp test that was running on the LAN and WLAN client machines:

  CPU[|||||||||||||||||||||||||||||||||98.1%]     Tasks: 16, 0 thr; 2 running
  Mem[||||||||||||                  23/123MB]     Load average: 0.47 0.35 0.18
  Swp[                                 0/0MB]     Uptime: 00:10:21

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 1134 root       20   0  1604   480   304 S 16.4  0.4  0:13.29 /usr/sbin/hostapd -P /var/run/wif
 1353 root       20   0  1372   772   544 R  5.3  0.6  0:01.06 htop
  884 root       20   0  1364   388   312 S  0.7  0.3  0:00.05 /usr/sbin/telnetd -F -l /bin/logi
  805 root       20   0  1484   708   500 S  0.0  0.6  0:00.35 /sbin/netifd
  831 root       20   0  1156   560   400 S  0.0  0.4  0:00.10 /usr/sbin/odhcpd
  910 root       20   0  1364   468   392 S  0.0  0.4  0:00.13 /usr/sbin/ntpd -n -p 0.openwrt.po
 1241 root       20   0  1604   608   432 S  0.0  0.5  0:00.18 /usr/sbin/hostapd -P /var/run/wif
    1 root       20   0  1396   624   436 S  0.0  0.5  0:02.50 /sbin/procd
  471 root       20   0   888   284   216 S  0.0  0.2  0:00.03 /sbin/ubusd
  472 root       20   0   772   212   156 S  0.0  0.2  0:00.01 /sbin/askfirst /bin/ash --login
  753 root       20   0  1040   416   268 S  0.0  0.3  0:00.06 /sbin/logd -S 16
  863 root       20   0  1152   420   348 S  0.0  0.3  0:00.03 /usr/sbin/dropbear -F -P /var/run
 1116 root       20   0   808   312   244 S  0.0  0.2  0:00.01 odhcp6c -s /lib/netifd/dhcpv6.scr
 1163 nobody     20   0   928   508   412 S  0.0  0.4  0:00.04 /usr/sbin/dnsmasq -C /var/etc/dns
 1293 root       20   0  1364   448   368 S  0.0  0.4  0:00.02 /bin/ash --login
 1303 root       20   0  1364   448   368 S  0.0  0.4  0:00.00 /bin/ash --login

Here's the /etc/config/wireless I used after installing kmod-ath10k:

config wifi-device 'radio0'
    option type 'mac80211'
    option path 'pci0000:01/0000:01:00.0'
    option txpower '17'
    option country 'US'
    option hwmode '11a'
    option htmode 'VHT80'
    option channel '36'

config wifi-iface
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'wlan-50'
    option encryption 'psk-mixed'
    option key 'PASSWORD'

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/qca955x_wmac'
    option txpower '30'
    option htmode 'HT40'
    option country 'US'
    option channel '1'

config wifi-iface
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option ssid 'wlan-24'
    option encryption 'psk-mixed'
    option key 'PASSWORD'

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

@Mastabog
Yes of course my BB setup was correct.   I have tested two different versions of BB.   My own compiled version and an older version.  I have four Archer C7s now.

It would be good if you could post your newer data for CC since you have a newer AC wireless card so we can see how CC support is progressing with benchmarks.

In regards to my tests I think it's relevant that even at AC600 there's a big improvement in CC.  I don't believe BB ath10k AC support is equivalent to CC.

Of course the three antennas for 3 MIMO don't have to be external.   My point was that I'm hardly going to strip my laptop and install an extra antenna just so I can have a higher spec AC wireless adapter nor am I going to buy a new laptop or install a bulky USB 3.0 adapter simply for that privilege.

(Last edited by dem on 27 Nov 2014, 20:28)

My CC   Archer C7 uses a lot of system irq when using a lot of wifi too.     The same happens with 2.4 Ghz though.

It would be interesting to see if this is the same within BB.     I just wonder whether the TP Link firmware is able to use some kind of hardware acceleration for Wifi that Openwrt doesn't support as has been suggested after earlier NAT benchmark test comparisons.

@dem did you see my post above? I just reported CC performance tested today from today's trunk. It's worse than BB.

As for your phone test, once again: when you're not using 3-streams (full hw capacity) then everything is much easier, lighter on the CPU, things will look more stable, etc ... but that's just misleading. Moreover, you're not even able to max out 2-streams on 11ac as your phone caps you at 250 Mbps. Your phone test is simply not relevant and should not be trusted, it's misleading in pretty much all respects.

Also, you don't need an 802.11ac router (3-stream or 2-stream) to hit 250 Mbps. 802.11n will do that just fine. You could force the router to 11n (not 11ac) and you'll see you can hit 250 Mbps quite easily -- but please keep in mind this thread is about AC1300 speeds; you could create another thread if you wish to investigate stability for sub-AC1300.

(Last edited by mastabog on 28 Nov 2014, 00:37)

Is there any development on this issue? I have just ordered a C7 (hopefully v2) and would like to see speeds above 500MBit/s in real world with OpenWRT

Have you read my post above from 4 days ago?

(Last edited by mastabog on 2 Dec 2014, 16:34)

The ath10k driver is developed here: http://wireless.kernel.org/en/users/Drivers/ath10k/ - and development seems active, they do not talk much about performance though.
The driver in CC was last updated 2014-11-04 accoding to PKG_VERSION in http://git.openwrt.org/?p=openwrt.git;a … le;hb=HEAD
The driver was "released" from the ath10k team at 2014-10-24. They have made a couple of pull requests (releases) since, if some developer updated to a newer release, the situation might improve.

The ath10k developers list a full hostapd configuration that is tuned for best possible throughput, have anybody tried that? It seems that there are some differences between the generated hostapd configuration and the one listed, but I do not know whether these differences are important. I only a 2x2 MIMO client and get 500-530 Mbit rather consistently.

I think PKG_VERSION refers to the date the opkg package was last modified for openwrt and not to the date the source files were last modified. Modifying the opkg package can happen for a ton of reasons not related to the actual source code of whatever is in the opkg package.

Is 5Ghz working in OpenWrt with Archer C7 V.2.0?

If yes. How can i setuo 5Ghz, in web interface or only via config file?

Tnx

I believe this link may be of interest in this thread.   :-)
http://lists.infradead.org/pipermail/at … 04062.html

@dagb that looks like a promising patch?

Anybody want to spool up a build of CC with that to see if their performance improves?

There appears to be other performance-related patches floating around, too. And a bit of discussion around them.

Glad to hear it! 

I'm definitely seeing a TX Bitrate showing as 6 Mbit/s where the RX Bitrate is as high as 1053 Mbit/s!

What's the expected rate we'd expect between two wireless clients? I don't have a machine with a gigabit NIC (ordered a USB3 one, though), but I'd like to help if anyone needs extra testing. I just got my C7 today and have avoided installing OpenWRT because I found this thread.

How can I test the connection speed to the router only? With openWRT installed I imagine I can just run the iperf server there and then test from my MPB, but I'm SOL running stock firmware, I guess.

Did someone try to build image without iptables at all, an use switch NAT if lan and wan are required . If CPU is the bottleneck than iptables is most likely the culprit. Iptables even if appears to do nothing, every packet is inspected and uses cycles. Every major new kernel release introduces new iptables feature and degrades performance.

switch nat???

you mean hwnat?

https://dev.openwrt.org/ticket/11779

That is hilarious to read.

It's a shame that it doesn't look like it'll get done.

One commented touched on something that I think could work. Why not at least expose the device through simple sysfs nodes or something, disable the sw NAT, and then write script to configure it (basically parse the config from the web and convert it to whatever we need to configure the hw in a similar manner).

Is anybody able to get the ac radio working on the C7 with current trunk? The problem I'm seeing is "ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2".

Here's the relevant full dmesg for the ath10k modules:

[  353.570000] ath10k_pci 0000:01:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0
[  353.920000] ath10k_pci 0000:01:00.0: Direct firmware load failed with error -2
[  353.920000] ath10k_pci 0000:01:00.0: Falling back to user helper
[  354.060000] ath10k_pci 0000:01:00.0: otp stream is empty, using board.bin contents
[  355.240000] ath10k_pci 0000:01:00.0: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.2-00082-4-2 api 3 htt 2.1 wmi 65.109.0.0 cal otp
[  355.250000] ath10k_pci 0000:01:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[  355.860000] ath: EEPROM regdomain: 0x0
[  355.860000] ath: EEPROM indicates default country code should be used
[  355.870000] ath: doing EEPROM country->regdmn map search
[  355.870000] ath: country maps to regdmn code: 0x3a
[  355.880000] ath: Country alpha2 being used: US
[  355.880000] ath: Regpair used: 0x3a

Actually I managed to fix this issue.  Just an FYI.

After you install your router software and install the kmod-ath10k package, download this firmware to your local computer:

https://github.com/kvalo/ath10k-firmwar … 0.2.4.13-1

Then copy it to the router's firmware directory:

scp firmware-3.bin_10.2.4.13-1 root@192.168.1.1:/lib/firmware/ath10k/QCA988X/hw2.0/firmware-3.bin

Then reboot the router, and you should be back up with the 5ghz network. (Still with the 6MB/s TX Rate though.)

Why it OpenWrt slower than stock firmware? I can help by shining a bit of light onto this subject. I'm developing custom firwmares based on OpenWrt but I'm not OpenWrt developer, still as I have few years of experience with OpenWrt I can explain why sometimes performance sucks.

OpenWrt has three main parts; linux kernel, software packages and wireless drivers. OpenWrt developers work on all of them. Consider the amount of code this is, and consider that all work is done by a handful of OpenWrt developers. If you work in software industry you know many people big companies hire to work on much smaller projects. So be thankful it works as good as it does, it is actually a miracle that it works as good as it does

Main issue is that wifi chip manufacturers don't offer open source wifi drivers. If Atheros and Broadcom understood Open source as Intel does then you would get absolutely top speed and reliability from OpenWrt wifi drivers. You don't get top notch performance with OpenWrt because Atheros and Broadcom are choosing not release quality open source drivers.

Linux, BSDx and OpenWrt developers can only use other means to get wifi devices to work, usually reverse engineering, and without support from wifi chip companies it is not easy to support all features, get awesome performance and stability.

This is a long way of saying, that if performance sucks on OpenWrt you should blame Atheros and Broadcom for not giving you (OpenWrt community) high quality open source drivers!

(Last edited by valentt on 17 Feb 2015, 21:56)

Hi,

I found a strange thing, with test in the first post. I have two clients, an iMac 27" (named lightning, with a Broadcom a/b/g/n/ac card, but one of three antenna connector destroyed, so i think, it's only working with dual stream, ip: 172.16.30.1 and 192.168.200.2), and a linux box (named hurricane, with a PCI based 1000Mbps network card with maximal speed ~650Mbps, ip: 172.16.30.252 and 192.168.200.1).

OpenWRT version: CC r44620 (for long time use, i need to mirror every package, so anyone can use r44620:  http://openwrt.czo.hu/ )

i ran the first test:

[root@hurricane ~]# iperf -c 192.168.200.2 -i 1 -w 6M -l 2M -p 6001
------------------------------------------------------------
Client connecting to 192.168.200.2, TCP port 6001
TCP window size:  416 KByte (WARNING: requested 6.00 MByte)
------------------------------------------------------------
[  3] local 192.168.200.1 port 37875 connected with 192.168.200.2 port 6001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  34.0 MBytes   285 Mbits/sec
[  3]  1.0- 2.0 sec  32.0 MBytes   268 Mbits/sec
[  3]  2.0- 3.0 sec  32.0 MBytes   268 Mbits/sec
[  3]  3.0- 4.0 sec  32.0 MBytes   268 Mbits/sec
[  3]  4.0- 5.0 sec  32.0 MBytes   268 Mbits/sec
[  3]  5.0- 6.0 sec  30.0 MBytes   252 Mbits/sec
[  3]  6.0- 7.0 sec  8.00 MBytes  67.1 Mbits/sec
[  3]  7.0- 8.0 sec  6.00 MBytes  50.3 Mbits/sec
[  3]  8.0- 9.0 sec  8.00 MBytes  67.1 Mbits/sec
[  3]  9.0-10.0 sec  26.0 MBytes   218 Mbits/sec
[  3]  0.0-10.1 sec   242 MBytes   201 Mbits/sec

When i remove -w and -l arguments, i get a bit better speed:

[root@hurricane ~]# iperf -c 192.168.200.2 -i 1 -p 6001
------------------------------------------------------------
Client connecting to 192.168.200.2, TCP port 6001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.200.1 port 37876 connected with 192.168.200.2 port 6001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  56.2 MBytes   472 Mbits/sec
[  3]  1.0- 2.0 sec  64.2 MBytes   539 Mbits/sec
[  3]  2.0- 3.0 sec  65.4 MBytes   548 Mbits/sec
[  3]  3.0- 4.0 sec  63.4 MBytes   532 Mbits/sec
[  3]  4.0- 5.0 sec  62.9 MBytes   527 Mbits/sec
[  3]  5.0- 6.0 sec  59.8 MBytes   501 Mbits/sec
[  3]  6.0- 7.0 sec  57.5 MBytes   482 Mbits/sec
[  3]  7.0- 8.0 sec  57.9 MBytes   485 Mbits/sec
[  3]  8.0- 9.0 sec  61.8 MBytes   518 Mbits/sec
[  3]  9.0-10.0 sec  61.5 MBytes   516 Mbits/sec
[  3]  0.0-10.0 sec   611 MBytes   512 Mbits/sec

but, when i test over LAN the two commands seems nearly identical:

[root@hurricane ~]# iperf -c 172.16.30.1 -i 1 -w 6M -l 2M -p 6001
------------------------------------------------------------
Client connecting to 172.16.30.1, TCP port 6001
TCP window size:  416 KByte (WARNING: requested 6.00 MByte)
------------------------------------------------------------
[  3] local 172.16.30.252 port 53861 connected with 172.16.30.1 port 6001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  1.0- 2.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  2.0- 3.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  3.0- 4.0 sec  76.0 MBytes   638 Mbits/sec
[  3]  4.0- 5.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  5.0- 6.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  6.0- 7.0 sec  76.0 MBytes   638 Mbits/sec
[  3]  7.0- 8.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  8.0- 9.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  9.0-10.0 sec  78.0 MBytes   654 Mbits/sec
[  3]  0.0-10.1 sec   778 MBytes   649 Mbits/sec
[root@hurricane ~]# iperf -c 172.16.30.1 -i 1 -p 6001
------------------------------------------------------------
Client connecting to 172.16.30.1, TCP port 6001
TCP window size:  325 KByte (default)
------------------------------------------------------------
[  3] local 172.16.30.252 port 53862 connected with 172.16.30.1 port 6001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  78.1 MBytes   655 Mbits/sec
[  3]  1.0- 2.0 sec  77.5 MBytes   650 Mbits/sec
[  3]  2.0- 3.0 sec  77.6 MBytes   651 Mbits/sec
[  3]  3.0- 4.0 sec  77.5 MBytes   650 Mbits/sec
[  3]  4.0- 5.0 sec  77.6 MBytes   651 Mbits/sec
[  3]  5.0- 6.0 sec  77.5 MBytes   650 Mbits/sec
[  3]  6.0- 7.0 sec  77.5 MBytes   650 Mbits/sec
[  3]  7.0- 8.0 sec  77.8 MBytes   652 Mbits/sec
[  3]  8.0- 9.0 sec  77.5 MBytes   650 Mbits/sec
[  3]  9.0-10.0 sec  77.8 MBytes   652 Mbits/sec
[  3]  0.0-10.0 sec   776 MBytes   651 Mbits/sec

When running tests over WiFi, i see very high software interrupt usage in GNU top on the router. I can't test with OEM firmware, becuse i used OEM firmware only to upload OpenWRT. Next weekend i wan't to test with two LAN clients with separated VLAN that bridged together (like wifi to lan bridge), to see CPU usage when forwarding packets LAN to LAN.

Related?

http://www.spinics.net/lists/linux-wire … 33009.html

Cheers.

Anyone tried on the latest firmware supported on OpenWRT firmware-4.bin_10.2.4.48?

Trunk currently uses firmware-4.bin_10.2.4.45 and iperf seemed to get really tangled on that version when used with my Note 4.  It would display the results on the Note 4 but the transmitting machine would think it hadn't finished for 10 seconds or so later, displaying a much lower result.

Quite frankly, I'm not sure if I trust iperf any more.  Because iperf is showing slower performance than older firmware, but real-world performance feels much much improved.  I just wish I had an 802.11ac adapter for PC but I sent the USB stick I had back as it was performing worse the 802.11n stick I have.

I suspect performance will still be iffy though as the SIRQ hits 80% when doing iperf to my Note 4 from a machine on the LAN and THAT is only reaching 350Mbit.  I'm certainly glad my Archer C7 is for WiFi only, it would kill the Internet performance.