Netgear R7800 exploration (IPQ8065, QCA9984)

[Magnetron1.1]

@dissent1
Sorry for the delay, but I've been testing and using Kong's R7800 DD-WRT builds for nearly 2 months.

For the iperf3 tests, I installed @hnyman build r5442.
My HP Pavilion dv7 laptop iperf3 server is running Ubuntu 16.04 LTS and using an Edimax AC1200 Wi-Fi adapter that is about 3.5 feet from the router.
The router Wi-Fi is set to AC 80 MHz bandwidth, channel 36, security WPA2 PSK, and tx power is 15 milliwatts.

Find the list of TCP congestion algorithms and the default one:

root@R7800RT1:~# sysctl -a 2>/dev/null|grep congestion
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_congestion_control = cubic

Sample iperf3 test using the default 'cubic' algorithm:

root@R7800RT1:~# iperf3 -c 192.168.16.107
Connecting to host 192.168.16.107, port 5201

[  5] local 192.168.16.1 port 51802 connected to 192.168.16.107 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  16.8 MBytes   141 Mbits/sec    0    724 KBytes       
[  5]   1.00-2.00   sec  14.4 MBytes   121 Mbits/sec    0   1.28 MBytes       
[  5]   2.00-3.00   sec  13.7 MBytes   115 Mbits/sec    0   1.68 MBytes       
[  5]   3.00-4.00   sec  17.8 MBytes   149 Mbits/sec    0   1.87 MBytes       
[  5]   4.00-5.00   sec  17.2 MBytes   144 Mbits/sec    0   2.19 MBytes       
[  5]   5.00-6.00   sec  16.6 MBytes   139 Mbits/sec    0   2.30 MBytes       
[  5]   6.00-7.00   sec  16.6 MBytes   140 Mbits/sec    0   2.42 MBytes       
[  5]   7.00-8.00   sec  16.1 MBytes   135 Mbits/sec    0   2.42 MBytes       
[  5]   8.00-9.00   sec  14.2 MBytes   119 Mbits/sec    0   2.42 MBytes       
[  5]   9.00-10.00  sec  16.0 MBytes   135 Mbits/sec    0   2.42 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   159 MBytes   134 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   158 MBytes   132 Mbits/sec                  receiver

iperf Done.

Sample iperf3 test using the 'reno' algorithm:

root@R7800RT1:~# iperf3 -c 192.168.16.107 -C reno
Connecting to host 192.168.16.107, port 5201

[  5] local 192.168.16.1 port 51818 connected to 192.168.16.107 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  18.2 MBytes   152 Mbits/sec    0   2.71 MBytes       
[  5]   1.00-2.00   sec  18.8 MBytes   158 Mbits/sec    0   2.74 MBytes       
[  5]   2.00-3.00   sec  19.9 MBytes   167 Mbits/sec    0   2.74 MBytes       
[  5]   3.00-4.00   sec  18.2 MBytes   152 Mbits/sec    0   2.74 MBytes       
[  5]   4.00-5.00   sec  16.5 MBytes   138 Mbits/sec    0   3.24 MBytes       
[  5]   5.00-6.00   sec  15.7 MBytes   132 Mbits/sec    0   4.69 MBytes       
[  5]   6.00-7.00   sec  18.9 MBytes   158 Mbits/sec    0   4.69 MBytes       
[  5]   7.00-8.00   sec  19.3 MBytes   162 Mbits/sec    0   4.69 MBytes       
[  5]   8.00-9.00   sec  16.5 MBytes   139 Mbits/sec    0   4.69 MBytes       
[  5]   9.00-10.00  sec  18.5 MBytes   155 Mbits/sec    0   4.69 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   180 MBytes   151 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   179 MBytes   150 Mbits/sec                  receiver

iperf Done.

I would say that the packet corruption and performance problems have been solved. Kudos to the Devs.

• Magnetron1.1

[Ansuel]

@dissent1 anyway now i have problem with luci.... it doesn't recognize rx / tx speed in the gui...
and why my device doesn't get 40 mhz?

[dissent1]

Are you sure that it's related? I mean that it wasn't this way before applying those patches?

[Ansuel]

i don't think it's related, it's just another bug... now that we fixed the big one we can move on the small one right?

[sdysj]

Glad to see WIFI issue being fixed, the next big issue is the stmmac driver that the LAN upload speed still stuck at 20Mbit/s.

Edit: Is someone try the nss-gmac? Some info https://patchwork.ozlabs.org/patch/426866/

[netrunnerx]

@hnyman,

I'm running the latest build on the R7800. I have a question about DHCP relay. I have two R7800, Router A is the DHCP server for my network and connects to my cable modem, Router B connects to just one wired host and one wifi host (GamingPC and TPCast for the HTC Vive VR HMD). The problem is I can't get Router B to relay DHCP from Router A for those two hosts. I've tried just about everything in the GUI. I'm wondering if this is a bug in the current build or I'm just missing something.

I ran this exact scenario sucessfully with a slightly different configuration of routers before (DIR-825 with DD-WRT as DHCP server, two Apple Time Capsules in bridge mode relayed DHCP from the DIR-825 quite well). Perhaps a simple way to enable a similar bridge mode would be valuable, I feel like it is a common use.

[clayface]

@hnyman @dissent1
I am currently running with cryptodev enabled and have improved openssl speed results for >16 byte blocks. Have you considered enabling this?

openssl speed -evp aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 21947.35k 75799.47k 268364.80k 557521.45k 1527808.00k

openssl speed aes-256-cbc
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256 cbc 49579.51k 57541.38k 58771.24k 60522.57k 58253.92k

Secondly I have been looking at the PVS table for ipq8065 to try and undervolt the router. I've simply copied the values for PVS bin 6 to 4 and compiled Is there any way to verify the voltages and what is applied?

Using 4.9 kernel

[dissent1]

@clayface

I am currently running with cryptodev enabled and have improved openssl speed results for >16 byte blocks. Have you considered enabling this?

How have you managed to do so?

@clayface

Secondly I have been looking at the PVS table for ipq8065 to try and undervolt the router. I’ve simply copied the values for PVS bin 6 to 4 and compiled Is there any way to verify the voltages and what is applied?

Probably no way to check this using current setup, but you can add some printk into the code directly so it just puts output into dmesg. But I wouldn't bother because as far as I know it doesn't have some kind of fallback mechanism and it just uses values provided in DT.

[clayface]

In the config, enable cryptodev in the kernel, followed by libopenssl

Kernel modules -> Cryptographic API modules -> kmod-cryptodev
CONFIG_PACKAGE_kmod-cryptodev=y
CONFIG_PACKAGE_kmod-crypto-cbc=y

Libraries -> SSL -> libopenssl -> Crypto acceleration support
CONFIG_OPENSSL_HARDWARE_SUPPORT=y
CONFIG_OPENSSL_OPTIMIZE_SPEED=y
CONFIG_OPENSSL_ENGINE_CRYPTO=y

I've not had time to fully test apart from the openssl speed test but imagine the speed improvement won't be all that great in openvpn due to overheads.

For the undervolt attempt, the reason I am sceptical is that even with the voltages set well below the defaults for pvs bin 4 in the dtsi file i have yet to experience any crashes, using 2 R7800s. Will investigate further.

[dissent1]

@clayface

In the config, enable cryptodev in the kernel, followed by libopenssl

Ah... I believe your results are faulty, there is no crypto engine enabled in our device, because there's no driver for that

@clayface

For the undervolt attempt, the reason I am sceptical is that even with the voltages set well below the defaults for pvs bin 4 in the dtsi file i have yet to experience any crashes, using 2 R7800s. Will investigate further.

As a matter of curiosity: what do you want to achieve? A selection of pvs bin 4 has been blown into efuse on factory for a reason

[McShauno]

ok @dissent1, well done. You've got to be pretty proud of this fix. Well, if you knew the number of people I had working on it and FINDING NOTHING you would be proud. Really cool.

-Shaun

[dissent1]

@McShauno

ok @dissent1, well done. You’ve got to be pretty proud of this fix. Well, if you knew the number of people I had working on it and FINDING NOTHING you would be proud. Really cool.

Actually tnx to @Ansuel , his msg was a last drop to check that 0071 patch, guess no one had thought that there's smth wrong.

Check this commit. This one was a real pain to find - u-boot uses 2 last MiBs of a memory region for its own needs thus corrupting other processes that also write there. It is not mentioned in GPL sources or at least was perfectly hidden.

ipq806x: add reserved memory node in Netgear R7800

[Ansuel]

Will try this patch asap something to test to make sure the problem is fixed?

[dissent1]

That's a 1 year old lede commit

[McShauno]

@dissent1

Actually tnx to @Ansuel , his msg was a last drop to check that 0071 patch, guess no one had thought that there's smth wrong.

Check this commit. This one was a real pain to find - u-boot uses 2 last MiBs of a memory region for its own needs thus corrupting other processes that also write there. It is not mentioned in GPL sources or at least was perfectly hidden.
https://github.com/lede-project/source/commit/8f7e58c0fea5cf3b88eeaa83298e3b852039dbb7

Unreal. "Perfectly hidden" is exactly right. Wow.

[netrunnerx]

@dissent1,
Have you released an img with the new memory fix?

also, I was reading up above somewhere about a 20mb/s lan uplink issue. Is that still an issue?

[dissent1]

That commit is already in lede for a year.
I haven't heard of any real LAN uplink issue, the one who posted about it probably had a bad cable.

[sdysj]

Nope, that's not cable issue.

Describe here:

Netgear R7800 exploration (IPQ8065, QCA9984)

Sorry to quote such an old post, but I do experience the same problem... I have 2 routers, Linksys EA8500 and Phicomm K3. EA8500 has an IPQ8064 which is much like R7800, and K3 has BCM4709. They all have the same problem as dissent1 described in that post (reproducible by all WiFi and wired connections). Data streams going out of the router are capped at 300Mbps (<100Mbps for WiFi) but streams flowing into the router are just fine. EA8500 is running at revision r49xx which was built several da…

This issue still exist on master branch.

[r43k3n]

+1 one for that one.
That would totally explain every single issue I have with my TP-Link C2600 (IPQ8084) and my 250/20 Mb connection. I've been asking about this a few times on the forum and I never came close to even narrowing down this issue.

Please keep in mind that this problem (the performance one) has been raised in this thread a few times and around this forum many times more. They've just been disregarded and never linked together. Saying it's an issue with bad cable is just wrong.

[dissent1]

2 new commits for testing
https://github.com/lede-project/source/pull/1569
https://github.com/dissent1/r7800/commit/aeb691df2c07cf7589d9695e38edadaa07ef1b87

The second one may have also a positive effect in our case, not only when using qca ssdk.

Update: updated the 1st link with PR. No difference code wise, adjusted the description and refreshed the patch.