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

You should start your own thread now.

Does this build support the new gd25q128 flash chip?

Just tried Archer-c7-v2-4.9.87-dhcpforwardnodns and I'm getting the worst speeds ever on this router. I can only get 328Mbit max out of a link speed of 866Mbit, and not consistently. The routers CPU is maxed out with SIRQ, as it did before but got at least 400Mbit in the past. :confused: Am I missing something?

I don't need anything fancy as I only use it as an AP, just the best WiFi speeds it can manage.

Pretty sure I used to get around 500Mbit in the early days when ath10k was just becoming usable (actual sustained Windows SAMBA copies at 60+Mbytes/sec). Not sure what went wrong since then, performance just seems to have gone downhill with each update.

SQM is off as no NAT should be taking place as its merely a WiFi Access Point.

RTS/CTS and BEACON are default, DISTANCE was on 5.

I'm wary to replace the bootloader as bricking the device is not fun.

I don't use 2.4Ghz on the C7 as I have an old WDR3600 on the network too that I was using just as a Switch so I moved the 2.4Ghz clients to that.

yeah i just did a fresh flash and still maxing out at 433.3

@sycohexor I really think you should start a new thread with your builds, because this belongs to @r00t and can be misleading.

2 Likes

@dacarrs
+1

1 Like

indeed - where is @r00t ? It's been a while... :slight_smile:

this is what im getting pretty consistent now:

wifi5

1 Like

@cliobrando
+1

That doesn't show anything useful, link rates were never the problem, throughput is.

So far I have tried your builds and the ones from the OP, fast_classifier does not appear to be used at all for LAN to WiFi traffic on either build even with skip_to_bridge_ingress set to 1.

So I'm back to my original assumption, this has zero benefit for a plain bridge connection like a WiFi AP.

So is it something to do with offload?

Its hard to make any conclusions with you having the overclocked bootloader.

Whatever it is, something must have increased the CPU load compared to earlier firmwares. Crosstalk is no doubt a partial factor as my speeds fluctuate, but when at 4am I'm struggling to hit 300Mbit vs the 500Mbit I got before, its clearly not the whole picture.

Install the boot loader the instructions are somewhere on this thread or my
topic with the firmware.if you want me to include kmod-mtd-rw in my next update i will. I also noticed in /sys/fast_classifier that skip_to_bridge_ingress is set to 0 by default. and offload_at_pkts is set to 128 by default. have you looked into that?

Yes, setting those makes no difference:

#cat debug_info
size=0 offload=0 offload_no_match=0 offloaded=0 done=0 offl_dbg_msg_fail=0 done_dbg_msg_fail=0

#cat offload_at_pkts
4

#cat skip_to_bridge_ingress
1

Hardware NAT For LEDE check this thread out. im gonna put a build up today without fast classifier. see if that helps with cpu consumption. Do you know anything about u32 classifier? cuz thats in the builds.

Flow offload only works on kernel 4.14, and I think it's not much different from fastpath (from a performance perspective).

well according to @alexatkinuk fast path doesnt even work. So whats the alternative?

There is no alternative to flowoffload, because flowoffload is the only option for mainline support (it is already part of kernel 4.16), which in turn gives you much less maintenance trouble and much more real world testing (e.g. sqm or other corner cases). There are even the first hardware offloading features emerging for flowoffload (mt7621), which will enable real hardware accelerated flowoffload for selected SOCs.

1 Like