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.
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?
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.
@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
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.
To sum up, or SQM or Fatpath, but not together 
.
1 Like
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?
1 Like
@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
Got it, thanks for clarifying.
Would you consider performance of hardware-based NAT and FastPath equal?
@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.
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.
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.
2 Likes
Hi @cliobrando. I want to build my custom firmware.bin file for my Archer C7 v2 with Infinitnet patches.
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!
I'm having consistent issues with my 2.4 Ghz N band, where all devices show connected both at the device and on the router, but there is no access to the internet or it crawls so much that it's unusable or things time out. 5Ghz AC and wired connections continue to function perfectly.
It will usually fix itself in an hour or 2, or after a power cycle.
I don't even know where to begin for debugging, any tips here? Is this still the best firmware package to use these days?
DD-WRT repo?
I tried em all the only one I was able to get close to 1 gb was the newest tp link firmware with hardware nat, even ddwrt latest beta with sfe wasnāt cutting it.
Try disabling legacy