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

[iamperson347]

I'm not sure, but my guess would be no. I'm not sure what the process is to get packages backported. If someone does, I would be willing to try. However, with a new build of openwrt on the horizon, I'm sure the devs are more focused on getting that buttoned up vs. accepting backports.

[nikandriko]

Hi, I'm trying to use the Archer C7 v4 on a 1Gbps connection.

I've read the LEDE threads and I understand the options are:

1. Qualcomm FastPath -- included in the LEDE Optimized Firmware and also here
2. Flow Offload -- this is not an option since it's only available on kernel 4.14 and current kernel is 4.9. Performance is similar to FastPath, so no need to consider this, just patiently wait.
3. Hardware-based NAT -- based on this discussion, use the ar71xx MIPS24k patches.
   Note: On a closer look, these patches are essentially FastPath, therefore hardware-based NAT is only available in stock firmware.

It strikes me though as interesting that the guy who built the LEDE optimized firmware for Archer C7 v2 although he included in his list of changes both hardware-based NAT and Qualcomm Fast Path, there's no mention of the hardware-based NAT in his summary of changes. Maybe ended up not using it or maybe FastPath was initially mislabelled as hardware-based NAT.

I have also NOT seen any performance results on the Archer C7. One reported result with h/w-based NAT actually shows performance degradation and the original post author hinted at other factors affecting LEDE performance outside the NAT piece. On this post, there's these - unsupported by results - comments:

LAN to LAN is 1gbps for sure. Wan to LAN is about 450-500 without hw Nat which is marginally meet your requirements.
Or you use community build with hw nat enabled, 700-800.

c7 with fastpath will do ~930 mb/s nat on static/dhcp ip and ~650mb/s on pppoe

Any thoughts?

[cliobrando]

@nikandriko
The only way to have Hardware NAT enabled is to use the stock TP-Link firmware, that's why FastPath/Offload are the only options for now.

LAN to LAN: you get stock speeds, no NAT involved here, just the switch.
LAN to WAN: using fastpath or offload you get close to 1Gbps. Shapping not compatible so no SQM.
PPPOE: not compatible with fastpath, that's why the speed drop (this has been reported in this forum)

Now, my personal use case, I have a wan connection < 300Mbps, so I unload the fastpath module and enable SQM Cake/piece_of_cake to reduce bufferbloat.

Btw, if you have a 1Gbps wan connection I recommend to buy a better router, even with the TP-Link stock firmware you will have slowdowns.

[Klingon]

I recommend you to buy an x86/x64 Fanless PC like:

Amazon.com: Ultra fanless mini pc with Dual Lan Intel Celeron J1900 8Gb Ram 128Gb Ssd Windows 10 Wireless cheap industrial nettop pc: Computers & Accessories

Install OpenWRT/LEDE and forget the rest of options.

I'm using a Fanless PC as router very similar to the one linked before (running LEDE + SQM + VPN IPSEC + Luci +....) and after 6 six months using it, my performance "problems" are over forever.
My old C7 v2 now is working as dumb AP (running OpenWRT).

Thanks,

[fernandofig]

How do I know if SQM and Fastpath are active? Because I have both enabled on my Archer C7, but can't tell if they're doing their work. I suppose at least SQM is, because my bandwidth drops about 10% (in average) when it's active, which I believe is expected when any kind of QoS is taking place.

[nikandriko]

The only way to have Hardware NAT enabled is to use the stock TP-Link firmware

I initially thought that the thread Hardware NAT for LEDE and the referenced MIPS24k GitHub repo had found a way for LEDE to do hardware-based NAT. However, in the referenced repo, FastPath is being mentioned. Did this end up becoming FastPath? Is the thread mislabelled?

[Klingon]

As far as I know, you can't have SQM + FastPath enabled at the same time.
When you enable SQM, automatically FastPath gets disabled.

You have to choose between SQM or FasthPath, but not both.

[cliobrando]

@fernandofig
To know if it's loaded you can type "lsmod" and see if fast_classifier is loaded or "lsmod | grep fast_classifier"
if you want to unload the module type "rmmod fast_classifier" and then "dmesg" you should see a message like "fast classifier unloaded" or something like that.
if you want to unload the module permanently delete the file /etc/modules.d/z-fast-classifier (I'm 90% sure of the correct filename)

@nikandriko
I think isn't mislabeled, the developers found the code for the Qualcomm shortcut engine driver, I guess they thought that was the hardware NAT implementation, but it was fast classifier, a "packet forwarding engine".

@Klingon
You can have both enabled, and if you enable SQM, fast path isn't automatically disabled.

[Klingon]

@cliobrando Take a look here:

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

@DjiPi I discovered that SQM and FastPath are mutually exclusive after a lot of testing. If you want to use SQM to reduce bufferbloat just disable FP. If you want to use FP to increase you network throughput don’t enable SQM.

[cliobrando]

@Klingon
Yep, I wrote that.
Maybe I didn't explain myself clear: Yes, you CAN have both enabled, BUT if you use SQM you MUST disable fastpath, otherwise performance will be impacted. Fast path isn't automatically disabled when you enable SQM.

[Klingon]

To sum up, or SQM or Fatpath, but not together .

[nikandriko]

I think isn’t mislabeled, the developers found the code for the Qualcomm shortcut engine driver, I guess they thought that was the hardware NAT implementation, but it was fast classifier, a “packet forwarding engine”.

So, I think that hardware-based NAT might NOT exist even in the stock TP-Link firmware. All that exists and has been discovered is the Qualcomm FastPath fast-classifier. Is this right?

[cliobrando]

@nikandriko
Hardware accelerated nat does exist, only that the code to make it work is not publicly available, offloading and fast classifier are just software alternatives to it.
Stock TP-Link Firmware = Hardware accelerated NAT enabled

[nikandriko]

Got it, thanks for clarifying.
Would you consider performance of hardware-based NAT and FastPath equal?

[cliobrando]

@nikandriko
Both are similar in performance, I don't think that even using hardware accelerated NAT you'll get a constant 1Gbps WAN connection, maybe 800Mbps and that's close you will get using fastpath or offload in openwrt.

[fernandofig]

My understanding is that you can have both enabled together, but the effect of doing so will be counter productive to their purpose - you'll lose performance instead of gain it.

I'll have a try later at disabling Fastpath and see how that goes.

[cliobrando]

My understanding is that you can have both enabled together, but the effect of doing so will be counter productive to their purpose - you’ll lose performance instead of gain it.

I’ll have a try later at disabling Fastpath and see how that goes.

That was mentioned a couple of posts before, and that's why you shouldn't use fast classifier and SQM, seems no one is reading the thread.

[fernandofig]

Yes, I got that - I was replying to @klingon, that seemed to not have understood that.

[nikandriko]

Wanted to share my WAN-to-LAN speed test results running jPerf server/client on a TP-Link Archer C7 v4 with different firmware types (stock, LEDE w/o FastPath, LEDE w/ FastPath, DD-WRT w/ SFE).

As you can see, DD-WRT's latest f/w achieves speeds higher than 900 Mbps which I have not experienced with LEDE. I have used gwlim's Archer C7 v4 builds and also created my own ones pulling in the FastPath patches, so sharing below the highest results I managed to achieve.

Wonder if you have any insights as to what DD-WRT might be doing differently since SFE is the exact same things as FastPath.

Stock TP-Link f/w with hardware-based NAT

bin/iperf.exe -c 192.168.85.59 -P 1 -i 1 -p 5001 -f m -t 10
------------------------------------------------------------
Client connecting to 192.168.85.59, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[228] local 192.168.0.154 port 49699 connected with 192.168.85.59 port 5001
[ ID] Interval       Transfer     Bandwidth
[228]  0.0- 1.0 sec   112 MBytes   938 Mbits/sec
[228]  1.0- 2.0 sec   111 MBytes   933 Mbits/sec
[228]  2.0- 3.0 sec   106 MBytes   891 Mbits/sec
[228]  3.0- 4.0 sec   114 MBytes   958 Mbits/sec
[228]  4.0- 5.0 sec   113 MBytes   946 Mbits/sec
[228]  5.0- 6.0 sec   113 MBytes   951 Mbits/sec
[228]  6.0- 7.0 sec   113 MBytes   950 Mbits/sec
[228]  7.0- 8.0 sec   114 MBytes   954 Mbits/sec
[228]  8.0- 9.0 sec   113 MBytes   949 Mbits/sec
[228]  9.0-10.0 sec   112 MBytes   937 Mbits/sec
[228]  0.0-10.0 sec  1121 MBytes   939 Mbits/sec
Done.

LEDE w/o FastPath

------------------------------------------------------------
Client connecting to 192.168.85.59, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[228] local 192.168.1.113 port 52907 connected with 192.168.85.59 port 5001
[ ID] Interval       Transfer     Bandwidth
[228]  0.0- 1.0 sec  33.6 MBytes   282 Mbits/sec
[228]  1.0- 2.0 sec  46.6 MBytes   391 Mbits/sec
[228]  2.0- 3.0 sec  34.1 MBytes   286 Mbits/sec
[228]  3.0- 4.0 sec  44.6 MBytes   374 Mbits/sec
[228]  4.0- 5.0 sec  45.3 MBytes   380 Mbits/sec
[228]  5.0- 6.0 sec  47.2 MBytes   396 Mbits/sec
[228]  6.0- 7.0 sec  44.6 MBytes   374 Mbits/sec
[228]  7.0- 8.0 sec  46.7 MBytes   392 Mbits/sec
[228]  8.0- 9.0 sec  44.8 MBytes   376 Mbits/sec
[228]  9.0-10.0 sec  33.2 MBytes   279 Mbits/sec
[228]  0.0-10.1 sec   421 MBytes   351 Mbits/sec
Done.

LEDE w/ FastPath

bin/iperf.exe -c 192.168.85.59 -P 1 -i 1 -p 5001 -f m -t 10
------------------------------------------------------------
Client connecting to 192.168.85.59, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[228] local 192.168.1.113 port 62155 connected with 192.168.85.59 port 5001
[ ID] Interval       Transfer     Bandwidth
[228]  0.0- 1.0 sec  84.7 MBytes   710 Mbits/sec
[228]  1.0- 2.0 sec  82.9 MBytes   695 Mbits/sec
[228]  2.0- 3.0 sec   100 MBytes   840 Mbits/sec
[228]  3.0- 4.0 sec   101 MBytes   850 Mbits/sec
[228]  4.0- 5.0 sec   105 MBytes   885 Mbits/sec
[228]  5.0- 6.0 sec   103 MBytes   863 Mbits/sec
[228]  6.0- 7.0 sec   104 MBytes   873 Mbits/sec
[228]  7.0- 8.0 sec  82.8 MBytes   694 Mbits/sec
[228]  8.0- 9.0 sec  81.7 MBytes   686 Mbits/sec
[228]  9.0-10.0 sec  84.6 MBytes   710 Mbits/sec
[228]  0.0-10.0 sec   931 MBytes   780 Mbits/sec
Done.

DD-WRT w/ SFE

• This is similar implementation as FastPath, see repo.

bin/iperf.exe -c 192.168.85.59 -P 1 -i 1 -p 5001 -f m -t 10
------------------------------------------------------------
Client connecting to 192.168.85.59, TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[144] local 192.168.1.113 port 62845 connected with 192.168.85.59 port 5001
[ ID] Interval       Transfer     Bandwidth
[144]  0.0- 1.0 sec   112 MBytes   936 Mbits/sec
[144]  1.0- 2.0 sec   108 MBytes   908 Mbits/sec
[144]  2.0- 3.0 sec   108 MBytes   903 Mbits/sec
[144]  3.0- 4.0 sec   111 MBytes   932 Mbits/sec
[144]  4.0- 5.0 sec   110 MBytes   919 Mbits/sec
[144]  5.0- 6.0 sec   110 MBytes   925 Mbits/sec
[144]  6.0- 7.0 sec   109 MBytes   912 Mbits/sec
[144]  7.0- 8.0 sec   108 MBytes   904 Mbits/sec
[144]  8.0- 9.0 sec   111 MBytes   930 Mbits/sec
[144]  9.0-10.0 sec   111 MBytes   933 Mbits/sec
[144]  0.0-10.0 sec  1097 MBytes   918 Mbits/sec
Done.

[nitromehmet]

Hi @cliobrando. I want to build my custom firmware.bin file for my Archer C7 v2 with Infinitnet patches.

infinitnet/lede-ar71xx-optimized-archer-c7-v2

I downloaded the patches but I don't have a clue what will I do with these How can I apply "064-luci-wifi-add-feature.patch" to original LEDE repository files? I want the option in LuCI "Force to use 40 MHz"
Thanks!