Qualcomm Fast Path For LEDE

It looks like replies to that overclocking thread are closed. Pity, as I've got some results to post. They're probably a little relevant to this thread, as I'd assume they'll impact the performance of software flow offloading.

I managed to get the breed bootloader installed and got my CPU running at 1000MHz. When I set the memory speed to Pedro's 760MHz if left me with a router that handed out an IP address but no gateway and was inaccessible (I tried setting a static IP on my computer, but no dice). So I booted back into breed, dropped the memory speed to 600MHz, and now everything appears to be great. I've got an Archer c7 v2 with a CPU at 1000MHz that's running openwrt snapshot and appears to be doing so with no issues. The router doesn't even feel warm.

Results of "openssl speed md5 sha1 sha256 sha512" before and after overclock:

before:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               3238.06k    11667.18k    31559.12k    54389.72k    68505.94k
sha1              3501.39k    10919.23k    26035.01k    39378.22k    46105.34k
sha256            3924.35k     9100.04k    15783.04k    19461.24k    20831.87k
sha512             814.69k     3257.65k     4490.40k     6058.87k     6750.87k

after:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               5565.14k    18416.74k    47276.66k    77263.15k    95332.93k
sha1              5662.74k    16754.37k    38145.64k    55831.23k    63852.92k
sha256            5705.37k    12839.87k    21992.41k    26999.59k    28838.87k
sha512            1136.98k     4552.83k     6248.48k     8448.00k     9375.74k

So a ~39% increase in speed of those calculations?

I ran a stopwatch on my phone for both the before and after runs, and clocked the first run at 1:02 and the second at 1:03 -- I'd assume those are both the same 1 minute of actual time plus a bit of human mechanical latency getting to the 'stop' button.

I did a couple of speed tests and got into the 4-600s for up and down, but it's not really the best test given that the limiting factor may not be the speed of the overclocked Archer c7 v2 with software flow offloading but instead the limit may be due to the speed provided by whichever server the speedtest was using. At the very least, those numbers are around the same as I was getting before the overclock and are better than I ever achieved before installing the firmware that included flow offloading. I'll do some more speed tests after I replace my current router with this one and set it up as the main router on my network and if it returns some better numbers I'll report them.

Ethernet switch speeds appear to have improved with overclocking combined with flow offloading -- this is a high score for today:
30%20PM

Here's a google spreadsheet showing the result of a bunch of tests, including speed tests of the following configurations:

  • Cable internet (300mbps down, 20mbps up), Archer c7 v4 running the 08-22-2018 snapshot of openwrt
  • 1Gbps Fiber internet, Archer c7 v4 running the 08-22-2018 snapshot of openwrt
  • 1Gbps Fiber internet, Archer c7 v2 running juppin's snapshot build with flow offloading, stock 720MHz CPU speed)
  • 1Gbps Fiber internet, Archer c7 v2 running juppin's snapshot build with flow offloading, CPU overclocked to 1000MHz, memory overclocked to 600MHz.

And a little chart (included in the spreadsheet). Flow offloading led to a clear increase in speed. Conclusions are a little foggy due to the low sample size (I've only got one non-overclocked flow offloading speed test data point) and an unreliable testing method that depends on the speed of remote servers. But I think I'm seeing a bit of a gain from overclocking.

31%20PM

1 Like

can you test the difference for overclocked without flow offload ?

I can try some more tests later today if I get time. I've got an ODROID-XU4 that ought to be able to saturate things with iperf to cut remote server speed variability out of the results.

But if you look at that one spike in the chart labelled "v2_fiber_720_flow", that's the existing measurement with flow offloading but no overclocking.

On a different note - here's a test result with flow offloading and overclocking of the router's 5GHz 802.11ac speed. I'm fairly distant from the router but with no walls in between and am getting a connection at -93dBm noise and -66dBm RSSI.

21%20AM

(edit - replaced a 271/238 test with a newer 373/293 wifi test result - computer in same position with same connection strength)

It would be interesting to see how the Fast Path patches compare (in benchmark test) with the “official” flow offload that’s now part of the 4.14+ kernel.

1 Like

For TP-Link 1043ND V1 gwlim's FastPath image performs a way better than the ath79 Flow offload. Especially in PPPoE environment.

FastPath:
DHCP: 641 Mbits/sec
PPPoE: 443 Mbits/sec

K4.14 Flow offload: see juppin's ath79 build topic

1 Like

Can you help me with a compiled fast path lede 17.01.5 for a D-Link DHP-1565 rev. A1?
Thank you.

I do not see any benefits of this patch, bandwidth is same, negligible differences.
Used iperf -s and iperf -c serveripaddress in LAN-LAN and WAN-LAN

Dlink Dhp-1565
openwrt 18.06.1 up 362.46 mbps / down 350.52 mbps
lede 17.01.5 up 294.90 mbps / down 246.02 mbps
DD-WRT v3.0-r37012 up 876.23 mbps / down 489.39 mbps

this is because DD-WRT has very unsecure firewall, if you optimize OpenWRT firewall or turn it off just for testing you can see same or even better speeds

Can you teach me how? I'm still learning how to work with Linux and these kinds ok things :laughing::laughing::laughing:

I've already tried that. If I disable the firewall I no longer have Internet connection.
But I'm open to any test given that I use lede-openwrt for a few years and dd-wrt for 1 day.
But I think the lack of hardware NAT is to blame.

obviously you did not disable firewall, try iptables to make sure it is disabled, should be like:
iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Should be ACCEPT on all tables nat, mangle etc and no rules
And also check ipv6 tables.

If you disable firewall, NAT will be disabled as well

The official LEDE build for Ubiquiti's ER-X has, in the firewall page, both "Software flow offloading" and "Hardware flo offloading" (the later specific to the mt7621 chipset).

Is this the same patch?

I have followed thes steps to make a build for PowerPC mpc85xx (TL-WDR4900)

I run ./patch_LEDE.sh and get the folowing error:

mins@ubuntumate:~/devel/lede$ ./patch_LEDE.sh 
Add QCA Repo
--2018-10-03 19:22:59--  https://source.codeaurora.org/quic/qsdk/oss/system/openwrt/plain/include/local-development.mk
Resolving source.codeaurora.org (source.codeaurora.org)... 35.154.29.226
Connecting to source.codeaurora.org (source.codeaurora.org)|35.154.29.226|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 440 [text/plain]
Saving to: ‘./include/local-development.mk’

local-development.mk            100%[======================================================>]     440  --.-KB/s    in 0s      

2018-10-03 19:23:00 (98,9 MB/s) - ‘./include/local-development.mk’ saved [440/440]

Updating feed 'packages' from 'https://git.openwrt.org/feed/packages.git' ...
Cloning into './feeds/packages'...
remote: Enumerating objects: 4419, done.
remote: Counting objects: 100% (4419/4419), done.
remote: Compressing objects: 100% (3722/3722), done.
remote: Total 4419 (delta 199), reused 3335 (delta 126)
Receiving objects: 100% (4419/4419), 2.62 MiB | 5.12 MiB/s, done.
Resolving deltas: 100% (199/199), done.
Create index file './feeds/packages.index' 
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..HEAD
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..2cc821e7edeafecc57ed9f3be46af4c322d58560
Checking 'working-make'... ok.
Checking 'case-sensitive-fs'... ok.
Checking 'proper-umask'... ok.
Checking 'gcc'... ok.
Checking 'working-gcc'... ok.
Checking 'g++'... ok.
Checking 'working-g++'... ok.
Checking 'ncurses'... ok.
Checking 'perl-thread-queue'... ok.
Checking 'tar'... ok.
Checking 'find'... ok.
Checking 'bash'... ok.
Checking 'patch'... ok.
Checking 'diff'... ok.
Checking 'cp'... ok.
Checking 'seq'... ok.
Checking 'awk'... ok.
Checking 'grep'... ok.
Checking 'getopt'... ok.
Checking 'stat'... ok.
Checking 'unzip'... ok.
Checking 'bzip2'... ok.
Checking 'wget'... ok.
Checking 'perl'... ok.
Checking 'python'... ok.
Checking 'git'... ok.
Checking 'file'... ok.
Checking 'ldconfig-stub'... ok.
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..HEAD
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..2cc821e7edeafecc57ed9f3be46af4c322d58560
Collecting package info: done
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..HEAD
fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..2cc821e7edeafecc57ed9f3be46af4c322d58560

I tried your SFE patch, it seems to have trouble offloading UDP connections

I've been finding that my router's a bit unstable -- wifi stops working properly (after a day or two, the wifi networks become inaccessible to new connections, and devices already connected to them appear to be connected but get no internet access). It's very odd. I have to clear it by power-cycling the router.

I tried reversing the overclock to see if that fixed the issue (I dropped the overclock from 1GHz down to 800MHz) but I'm still running into the same wifi radio or network instability.

I'm not sure how to track down the problem. Next time it happens I'll see if it's only affecting wireless connections or is also affecting wired clients. And if wire clients can still connect to the router I'll poke around and see if there's anything apparently wrong.

For what it's worth, I'm running the same fast path build, and am also using 802.11r to do the fast handoff with another openwrt router configured as an access point with no DHCP.

Hi folks
Is this feature already integrated to snapshot OpenWrt builds or even since any specific version ?

Mentioning specifically some well known hardware does it come on vanilla builds for TP-LInk WDR3600, WDR4300 and Archer C7 (all versions) ?

i doubt it will ever be integrated as there is really no benefit, 4.14 has some offloading