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

@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

i love my raspberry pi soc on 4.14, just thought id throw that in there

@slh
Yep, I know, there's no alternative to flow offload, but 4.9 lede kernel only has fast path patches (for now). And if you compare flow offload performance (no hw assistance, current implementation) vs fast path, there's no much difference. Well, fastpath and flow offload share some principles.

@sycohexor
I don't know how do you know that fastpath is not working, it's easy to check using:
/sys/fast_classifier/debug_info

Fastpath and wifi are CPU dependent, that's why if you overclock the SoC get better performance, you can search benchmarks in this forum to compare with other users.

oh yup youre right, its working for me!!

size=156 offload=0 offload_no_match=0 offloaded=138 done=102 offl_dbg_msg_fail=138 done_dbg_msg_fail=102

size=107 offload=0 offload_no_match=0 offloaded=138 done=102 offl_dbg_msg_fail=138 done_dbg_msg_fail=102

cat /sys/fast_classifier/skip_to_bridge_ingress
0

cat /sys/fast_classifier/offload
128
cat /sys/fast_classifier/exceptions

PACKET_BROADCAST = 133
PACKET_MULTICAST = 333063
NO_IIF = 19555
CT_NO_CONFIRM = 15364020
TCP_NOT_ASSURED = 15311810
TCP_NOT_ESTABLISHED = 8682
UNKNOW_PROTOCOL = 13030
NO_SRC_DEV = 93
NO_DEST_DEV = 11619
WAIT_FOR_ACCELERATION = 568227
UPDATE_PROTOCOL_FAIL = 8682
CT_DESTROY_MISS = 15318580

Anybody see anything i can improve there?

I think you are misunderstanding, I'm not using NAT because I'm only using it as an Access Point. As such I wasn't expecting fast path to do anything for me, but some people were claiming it DID improve WiFi to LAN speeds, thus I tried it.

If you are using NAT, especially if your broadband speed is close to the hardware limit of the CPU, then sure it will work and help with WiFi performance when NAT is pushing a lot of bandwidth because its leaving more CPU available.

But for the LAN to WiFi bridge, it does nothing, sadly.

Guess fast classifier is useless then. I’ll remove it

How is it useless? It reduces CPU load for NAT so that when you are maxing out your broadband it impacts the WiFi speed less.

Useless for me sure, but when used as an actual router surely that extremely useful?

Or do you mean the alternative in the mainline kernel will effectively do the same?

Wow! this thread is pretty long now!

How can I tell with version of r00t's firmware I'm running?
My status page shows "LEDE Reboot SNAPSHOT r5464-5a8e9846af / LuCI Master (git-17.342.53118-6d086bf)"

Also, is r00t planning on release future releases? I couldn't tell by browsing through this thread!

thanks

I'm using my Archer C7 v2 as AP (not as router), the only way to improve performance in Wifi/LAN is overclocking via breed u-boot. Checked by myself.

After overclocking from 720 Mhz. to 1 Ghz. I've improved my connections about a 30% (the difference between 720 and 1000, about a 30% in Mhz.)

It's supposed NAT will improve as well after overcloking, but as I told before, I'm not using it.

Thanks,

i think most people are using his config file and patches etc now and building there own images mostly, or just keeping his as there stable version. Who knows....

where did you notice the change in performance does your kernel log still say 720?