[GCC 7.2 BUILD] Optimized TP-Link Archer C7 V2 AC1750 LEDE Firmware

Community Builds, Projects & Packages
86

Just as a modem. It's a Arris SB6183 modem, with a 1Gb eth out. Gives me
a public IP address to the router. I assume you meant "on cable" to mean
on ethernet. As I said, my cable system performance might be better than
average, and my stress test has been DSLReports Speed test during low
local load. Not sure if that's equivalent to your use case. I did note
improvement, even when it's maxing out, so there could be benifits to
running that way.

We should move this to a new thread, in the main "Installing and Using"
section... would be easier to look up later for others, too... Was going
to ask abt link layer adaptation settings, but this is getting a bit off
topic...

87

Heyas! I have an Archer C7v2, and love the build! :slight_smile:

Num 1 Comment:
Maybe a bit early right now to adopt this, but some people are working on enabling the Hardware NAT for LEDE: Hardware NAT For LEDE
gwlim is trying to set this up for his WNDR* (mips - 74kc) devices, but it should work on Archer C7 which uses the AR8327N switch (same as the tl-wdr4300). Would just need to configure the switch registers for ISIS to get it working. Can use their ssdk_sh to access the switch register configuration utility. If HWNAT comes to the Archer C7/LEDE, there would be no reason to go back to Original FW vs LEDE!
I do not think it's currently ready, basically someone needs to figure out the ssdk_h commands to enables the registers. blogic in the thread says he has a working qca8k driver which may be comming soon. So yea exciting stuff.
[EDIT: Edited out the quote, just realized when he said "these patches are great", he wasn't talking about that threads patches, but patches the poster did elsewhere.]

Num 1a Comment:
That said, gwlim from that thread has a number of other patch "optimizations" he does for his WDR* devices. You can go to that thread and see his patches listed sequentially. Hardware is very similar to our ArcherC7, and some may work in this threads firmware. His github patches are:

Num 2 Comment:
As for the SHA performance decreases, maybe something to do with the OpenSSH vs Hostapd Internal Crypto stuff? I know OpenSSH has optimised versions for mips, which greatly improve AES performance (for a bit larger binaries). I know you have both installed, so maybe somewhere in the configuration you don't have OpenSSH set for default and it's using the hostadp internal stuff cuz it see's it's installed (I know issues where people had both installed and WPA_SUPPLICANT_INTERNAL in config vs WPA_SUPPLICANT_OPENSSL). Just a thought, I haven't looked into it.

Num 3 Comment:
I see you are using the ath10k-CT firmware (modified qca 10.1.467), over the default original kvalo firmware (original latest qca 10.2.4-1.0). I was just curious on why you choose the -ct ones? Both are updated often (~2.5 months ago). I'm not saying one is better or worst, I was just curious if you choose -ct for a specific reason? Do you get better performance? Did you notice some bug fixes with -ct? Any reason in specific? I haven't tried the -ct firmware, I've been wanting too, to see if it fixes the archer c7v2 crashes with the new QCA61x4A wireless cards under load (dell xps 13 9360, acer swift 3, ect). Just haven't got around to it yet.

Num 4 Comment:
This has everything I need, except my "tor". I use my router to run a tor relay. So you can access .onion websites with a sock5 proxy through ur router when u need to access those sites. Some people also set it up through a hidden SSID, so u can go through ur tor with that. There is no luci module for tor currently though. I also perfer the "luci-theme-material" theme.

Num 5 Comment:
Have you played around with the SQM scripts on the Archer C7v2? I know performance is very specific for certain hardware. It would be nice to know which is best for the Archer C7v2. I know cake is accepted as the general default. Be nice to know if one of the other more unique ones performs better on our hardware.
I extensively tested it a long time ago (~6 months). At this time cake wasn't available, but i tested other scripts "simple.qos" was the default. But what I found is most of them would solve bufferbloat, but limit the upload/download much to much. I found the most simple solution was to install "luci-app-qos", and just manually limit the uplink/downlink. I was able to solve my bufferbloat perfectly and get a much higher uplink and downlink speed with this compared to sqm-qos. Again this was tested way back when, and we never had cake, or piece-of-cake back then. So they weren't tested. On my 50/10 connection (maxes near ~55/~11.5), my bufferbloat gets an A+ with 51.1/9.4, using just the simple luci-app-qos and tweaking it to max out uplink. So have you tested these scripts to see which is the best performance? Or is it just using the default cake currently? I'm fine with sqm-qos, just want to make sure I get the same or better performance compared to the simple-qos tweeked version.

Love the build! Keep up the good work!

1 Like
88

gwlim comment::

That was my comment, I can assure you that its not because of WPA_SUPPLICANT_OPENSSL this change was added after the fact.

89

hehe, yes, he has one for WDR4300 as I said... but that is not the Archer C7. We can't flash that firmware on the Archer C7. What I was saying is that the Archer C7 and WDR4300 use the same switch. So if he built one for the WDR4300, then it should be easy to adapt to the Archer C7. I.e. Including the ssdk-shell.patch in this firmware, and configuring the switch registers may improve performance on the ARCHER C7.

I never said it was because of WPA_SUPPLICANT_OPENSSL. I was just saying maybe it's some other configuration preferring hostadp over openssh, since both are installed (like the WPA_SUP... issue). Not that it was the WPA_SUP... issue.

90

theres no reason to adapt - he already made a statement that as long as the switch is supported it should be ready to go - you just need to setup it up yourself

91

That's all I was saying. Is that that ssdhk_h patch from the "hardware-nat-for-lede" thread can be applied into this Optimised Archer C7 firmware here. Was just letting the maintainer know about the work being done over there.
[edit: realised he was saying his wireless performance increases was coming from gwlin optimisation patches, not that threads hwnat patches.]

92

To your num 5 comment... Cake is supposed to take less CPU than fq_codel, as well as being more evolved. I read a presentation from one of the developers mentioning that. I just posted some data from testing on a C7, look in the Installing and Using section for a thread abt C5 and C7 and 5Ghz Wifi speeds.

Basically, a C7 can handle at least 120-130mbit, running Cake and Piece of Cake. You've got no problem with the 50/10mbit connection. Lots of headroom to run other stuff...

Now, getting the hardware NAT working, wonder how much better it would do on my faster connection. That would be awesome...

93

How fast does one's internet connection need to be before HW NAT becomes an advantage?

94

Probably more then 200Mb/s-250Mb/s (without any QoS/SQM, since it brakes HNAT) on Archer C7. More powerful units like Archer C2600 can handle 800Mb/s.

95

Hi thanks for the build I like the thinking behind it.

With respect to performance I was benchmarking this build against the Toke December build. Any ideas on why the performance difference?

Test setup
Host A (iperf3 client) —> WiFi —> Ethernet LAN Bridge —> Host B (iperf3 server)

C7v2(C5 hardware) root’s Lede Optimised Build
user@linuxhost ~ % iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.10 port 34172 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 35.7 MBytes 299 Mbits/sec 0 1.63 MBytes
[ 4] 1.00-2.00 sec 37.5 MBytes 315 Mbits/sec 0 3.02 MBytes
[ 4] 2.00-3.00 sec 36.2 MBytes 304 Mbits/sec 0 3.02 MBytes
[ 4] 3.00-4.00 sec 37.5 MBytes 315 Mbits/sec 1 2.22 MBytes
[ 4] 4.00-5.00 sec 36.2 MBytes 304 Mbits/sec 0 2.41 MBytes
[ 4] 5.00-6.00 sec 37.5 MBytes 315 Mbits/sec 0 2.57 MBytes
[ 4] 6.00-7.00 sec 40.0 MBytes 336 Mbits/sec 0 2.70 MBytes
[ 4] 7.00-8.00 sec 36.2 MBytes 304 Mbits/sec 0 2.80 MBytes
[ 4] 8.00-9.00 sec 36.2 MBytes 304 Mbits/sec 0 2.88 MBytes
[ 4] 9.00-10.00 sec 35.0 MBytes 294 Mbits/sec 0 2.94 MBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 368 MBytes 309 Mbits/sec 1 sender
[ 4] 0.00-10.00 sec 368 MBytes 309 Mbits/sec receiver

C7v2(C5 hardware) Toke build kau.toke.dk/lede/airtime-fairness-builds/ar71xx/generic/
user@linuxhost ~ % iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.10 port 34184 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 44.5 MBytes 373 Mbits/sec 0 1.98 MBytes
[ 4] 1.00-2.00 sec 46.2 MBytes 388 Mbits/sec 0 2.96 MBytes
[ 4] 2.00-3.00 sec 46.2 MBytes 388 Mbits/sec 0 2.96 MBytes
[ 4] 3.00-4.00 sec 46.2 MBytes 388 Mbits/sec 0 2.96 MBytes
[ 4] 4.00-5.00 sec 47.5 MBytes 398 Mbits/sec 0 2.96 MBytes
[ 4] 5.00-6.00 sec 45.0 MBytes 377 Mbits/sec 0 2.96 MBytes
[ 4] 6.00-7.00 sec 47.5 MBytes 399 Mbits/sec 0 2.96 MBytes
[ 4] 7.00-8.00 sec 46.2 MBytes 388 Mbits/sec 0 2.96 MBytes
[ 4] 8.00-9.00 sec 47.5 MBytes 398 Mbits/sec 0 2.96 MBytes
[ 4] 9.00-10.00 sec 46.2 MBytes 388 Mbits/sec 0 2.96 MBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 463 MBytes 389 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 463 MBytes 388 Mbits/sec receiver

96

Interesting, thanks for sharing this. My build actually has worse OpenSSL benchmark stats than the stock version as well (see posts above yours). I haven't had time to look into this yet and just keep it updated as it is for now. 80Mbps speed difference is huge though. @tohojo doesn't publish his configs as far as I can see, so I can't compare them to mine to figure out what could be the cause of that difference.

97

Here is another benchmark with the latest LEDE release 17.01.0 -- NO ADDITIONAL (e.g. PACKAGES) INSTALLED

Perhaps it's the ath10k CT drivers?

C7v2(C5 hardware) Lede 17.01.0 target build
user@linuxhost ~ % iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.10 port 34208 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 59.9 MBytes 502 Mbits/sec 0 2.75 MBytes
[ 4] 1.00-2.00 sec 73.8 MBytes 619 Mbits/sec 0 3.03 MBytes
[ 4] 2.00-3.00 sec 63.8 MBytes 535 Mbits/sec 1 2.16 MBytes
[ 4] 3.00-4.00 sec 66.2 MBytes 556 Mbits/sec 0 2.37 MBytes
[ 4] 4.00-5.00 sec 63.8 MBytes 534 Mbits/sec 0 2.54 MBytes
[ 4] 5.00-6.00 sec 71.2 MBytes 597 Mbits/sec 1 2.19 MBytes
[ 4] 6.00-7.00 sec 73.8 MBytes 620 Mbits/sec 1 2.22 MBytes
[ 4] 7.00-8.00 sec 72.5 MBytes 608 Mbits/sec 0 2.41 MBytes
[ 4] 8.00-9.00 sec 67.5 MBytes 566 Mbits/sec 0 2.57 MBytes
[ 4] 9.00-10.00 sec 67.5 MBytes 566 Mbits/sec 0 2.70 MBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 680 MBytes 570 Mbits/sec 3 sender
[ 4] 0.00-10.00 sec 679 MBytes 569 Mbits/sec receiver

98

I just uploaded a new build. @hobbsAU it would be awesome if you could run iperf on your setup again to see if you get any different results with the new release. If not, I might switch to vanilla ath10k instead of CT to see if that might be the cause, although that's unlikely.

@all thanks for all your feedback and sorry that I didn't respond to every message. However, I've still taken your feedback seriously and applied some requested changes/additions to the new build.

PS. @hobbsAU just saw you also thought it might be the CT drivers, lol. New build will be up in a few, please test it if you have time and let me know the results. If the performance issues still exist, I'll switch to vanilla ath10k right away so you can compare the two using same base/configs.

PPS. Build is up.

99

@r00t Thanks will try your new build - give me a few mins.

BTW you caught me in the middle of testing the stock TPLINK firmware.. results below..

C7v2(C5 hardware) TPLINK Stock Firmware v3.14.2 Build 150304 Real.58409n
user@linuxhost ~ % iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.10 port 42674 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 62.4 MBytes 523 Mbits/sec 0 2.92 MBytes
[ 4] 1.00-2.00 sec 81.2 MBytes 682 Mbits/sec 0 3.06 MBytes
[ 4] 2.00-3.00 sec 83.8 MBytes 703 Mbits/sec 0 3.06 MBytes
[ 4] 3.00-4.00 sec 82.5 MBytes 691 Mbits/sec 0 3.06 MBytes
[ 4] 4.00-5.00 sec 82.5 MBytes 692 Mbits/sec 0 3.06 MBytes
[ 4] 5.00-6.00 sec 81.2 MBytes 682 Mbits/sec 0 3.06 MBytes
[ 4] 6.00-7.00 sec 82.5 MBytes 692 Mbits/sec 0 3.06 MBytes
[ 4] 7.00-8.00 sec 85.0 MBytes 714 Mbits/sec 0 3.06 MBytes
[ 4] 8.00-9.00 sec 82.5 MBytes 691 Mbits/sec 0 3.06 MBytes
[ 4] 9.00-10.00 sec 82.5 MBytes 693 Mbits/sec 0 3.06 MBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 806 MBytes 676 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 806 MBytes 676 Mbits/sec receiver

100

Wow, thanks for sharing these. Looks like there is plenty of room for improvement of both this and Toke's build compared to stock and vanilla LEDE.

101

@r00t results from your new 20170319 build..

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 365 MBytes 306 Mbits/sec 1 sender
[ 4] 0.00-10.00 sec 364 MBytes 305 Mbits/sec receiver

102

@hobbsAU Thanks. I'm completely removing mips16 instructions now and will also switch to vanilla ath10k drivers. Will let you know when that build is up - hopefully that will change something, else I'm kinda out of ideas and would have to rebuild every setting from scratch and compile & test after each change to pin it down, which you can imagine would take lots of time.. So let's hope the changes I'll do now will resolve this.

103

@r00t Hopefully that will make the difference. Look forward to testing out..

104

@hobbsAU New build is up. Didn't fix the OpenSSL benchmark performance issues, but hopefully it at least fixes the network performance.

105

@r00t I've just tested your latest build, there is a small improvement..

C7v2(C5 hardware) r00t’s LEDE Optimised Build 20170319_2
user@linuxhost ~ % iperf3 -c 192.168.1.20
Connecting to host 192.168.1.20, port 5201
[ 4] local 192.168.1.10 port 44112 connected to 192.168.1.20 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 38.7 MBytes 324 Mbits/sec 0 1.78 MBytes
[ 4] 1.00-2.00 sec 38.8 MBytes 325 Mbits/sec 0 3.01 MBytes
[ 4] 2.00-3.00 sec 40.0 MBytes 336 Mbits/sec 0 3.01 MBytes
[ 4] 3.00-4.00 sec 40.0 MBytes 335 Mbits/sec 0 3.01 MBytes
[ 4] 4.00-5.00 sec 41.2 MBytes 346 Mbits/sec 0 3.01 MBytes
[ 4] 5.00-6.00 sec 38.8 MBytes 325 Mbits/sec 0 3.01 MBytes
[ 4] 6.00-7.00 sec 41.2 MBytes 345 Mbits/sec 0 3.01 MBytes
[ 4] 7.00-8.00 sec 41.2 MBytes 347 Mbits/sec 0 3.01 MBytes
[ 4] 8.00-9.00 sec 38.8 MBytes 325 Mbits/sec 0 3.01 MBytes
[ 4] 9.00-10.00 sec 38.8 MBytes 325 Mbits/sec 0 3.01 MBytes

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 397 MBytes 333 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 397 MBytes 333 Mbits/sec receiver