flug
May 22, 2020, 2:08pm
1
Hello,
I have just got a BT Homehub 5a installed with 19.07 and OpenVPN-OpenSSL
The BT WAN port is connected to my DSL router and obtains IP connection ok, Open VPN is running using NordVPN.
Its all working, but I have been doing some testing.
So downloading a bittorrent Wifi through VPN to my mobile i am getting max download of 575kb/s
If I connect my phone to my DSL router wifi and use the OpenVPN android app to connect to the same VPN server and download the same torrent i am getting max download of 1200kb/s
Double the download rate.
Internet speed tests confirm similar differences in performance testing. As I will probably use VPN for Netflix, having 10mb instead of 6 would be preferable.
Could this be related to a bug i see mentioned where the router is only using 1 CPU,
Also, from other tests, wired performance has similar results.
Is there anything else I should check?
Thanks in advance for any help.
The HH5a isn't particularly powerful. At best you might get 8-9 mbit/sec out of it. Take a look at https://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=279 , it's pretty detailed on how to set everything up right.
flug
May 22, 2020, 2:32pm
3
Thanks,
Ahh, that looks like that will be the problem, AES 256 too much burden on the CPU.
Being new to this, is it possible to edit the VPN files for NordVPN to use AES 128 or something less intensive on the CPU?
i.e change cipher setting?
or even Socks5 VPN
1 Like
It's absolutely mandatory to switch to 128-bit encryption on a low-performance devices like home wifi routers.
In the case of 256-bit encryption you will be unable to get any reasonable throughput because of lack of AES-NI instructions.
Try to ad the following lines to your OpenVPN client config file:
# Disable cipher negotiation (otherwise negotiated cipher overrides --cipher)
ncp-disable
# Switch to 128-bit cipher
cipher AES-128-CBC
;cipher AES-128-GCM
If your VPN provider does not support AES-128-CBC, try to use AES-128-GCM.
Also I would strongly recomment to add the following line to yout OpenVPN client config
# Set the TX queue length on the TUN/TAP interface (default=100).
# Increase the transmission queue length to keep the TUN busy to get higher throughput.
txqueuelen 1000
In most cases this setting will boost your OpenVPN performance even more.
Refer to https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux for details.
And don't forget to enable RPS/XPS Packet steering (disabled/broken by default in 19.07).
Without packet steering enabled your network performance will be 2 times lower than should be.
See details at:
[FS#2573 : BT Home Hub 5A xrx200 performance degradation caused by RPS XPS commit]
opened 01:19PM - 29 Oct 19 UTC
closed 07:47AM - 07 Mar 20 UTC
flyspray
*bill888:*
Known to affect BT Home Hub 5A. Other similar Lantiq xrx200 device… s are likely to be affected too.
When OpenWrt 18.06 was released, it was observed that WAN to LAN throughput had suffered degradation. Maximum throughput dropping from 140 mbps to 80 mbps.
Some investigative testing was conducted when 18.06.1 was released.
[[https://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=1105|ebilan forum]]
It was discovered this commit was responsible for the fall in maximum throughput.
[[https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=916e33fa1e14b97daf8c9bf07a1b36f9767db679|netifd: update to the latest version, rewrite RPS/XPS handling]]
No one at the time thought it was a bug. In the UK, there is no support for VDSL vectoring, and so maximum DSL speeds is 80 Mbps which equates to 76 Mbps in real world speed tests through to the LAN ports.
Removing the above commit restored maximum possible throughput with 18.06.
mkresin recently took some time to look at this commit. Here are his comments:
First of all, it is about receive packet steering (rps) and transmit
packet steering (xps). rps/xps allows to specify which cpus/cores should
process transmitted and/or received packets. It is expressed as a
bitmask reading from right to left:
<cpu7> <cpu6> <cpu5> <cpu4> <cpu3> <cpu2> <cpu1> <cpu0>
For example:
Only cpu 0 should handle something: 00000001 (decimal 1)
Only cpu 1 should handle something: 00000010 (decimal 2)
cpu0 & cpu 1 should handle something: 00000011 (decimal 3)
I'm not yet sure what's the result of setting decimal 0.
The commit you already identified, changes the logic to not steer
packets to the cpus/cores handling the interrupts (cat /proc/interrupts).
Fun fact, the check which cpu/core handles the interrupts doesn't work
for lantiq, nevertheless the correct cpu/core is returned by accident.
It seems to me, that on some targets this change increases the max.
packet throughput, while it causes a degradation on lantiq. I've no idea
which targets benefit from the change nor for which targets it
introduces a degradation. Neither do I know why targets behave that
different.
<code>
First column of numeric values are from **Maurer's custom 18.06.4 for HH5A** which does not contain above RPS/XPS commit.
Second column is from 18.06.4 for HH5A.
Third column is from 19.07-snapshot-r10605 for HH5A.
Receive Packet Steering
/sys/class/net/br-lan/queues/rx-0/rps_cpus: 3 0 0
/sys/class/net/eth0.1/queues/rx-0/rps_cpus: 3 0 0
/sys/class/net/eth0.2/queues/rx-0/rps_cpus: 3 0 0
/sys/class/net/eth0/queues/rx-0/rps_cpus: 3 2 2
/sys/class/net/lo/queues/rx-0/rps_cpus: 3 0 0
/sys/class/net/wlan0/queues/rx-0/rps_cpus: 0 2 2
/sys/class/net/wlan1/queues/rx-0/rps_cpus: 0 2 2
RPS flow count
/sys/class/net/br-lan/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/eth0.1/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/eth0.2/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/lo/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/wlan0/queues/rx-0/rps_flow_cnt: 0 0 0
/sys/class/net/wlan1/queues/rx-0/rps_flow_cnt: 0 0 0
Transmit Packet Steering
/sys/class/net/br-lan/queues/tx-0/xps_cpus: 3 0 0
/sys/class/net/eth0.1/queues/tx-0/xps_cpus: 3 0 0
/sys/class/net/eth0.2/queues/tx-0/xps_cpus: 3 0 0
/sys/class/net/eth0/queues/tx-0/xps_cpus: 3 2 2
/sys/class/net/lo/queues/tx-0/xps_cpus: 3 0 0
/sys/class/net/wlan0/queues/tx-0/xps_cpus: 0 2 2
/sys/class/net/wlan0/queues/tx-1/xps_cpus: 0 1 1
/sys/class/net/wlan0/queues/tx-2/xps_cpus: 0 2 2
/sys/class/net/wlan0/queues/tx-3/xps_cpus: 0 1 1
/sys/class/net/wlan1/queues/tx-0/xps_cpus: 0 2 2
/sys/class/net/wlan1/queues/tx-1/xps_cpus: 0 1 1
/sys/class/net/wlan1/queues/tx-2/xps_cpus: 0 2 2
/sys/class/net/wlan1/queues/tx-3/xps_cpus: 0 1 1
</code>
<code>
'Best' possible throughput observed during testing from red WAN ethernet port to LAN port. (Results likely to be similar for VDSL to LAN port)
**maurer's custom 18.06.4 for HH5A without above RPS/XPS commit** for reference
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[ 4] local 192.168.1.162 port 51716 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 17.3 MBytes 145 Mbits/sec
[ 4] 1.00-2.00 sec 17.3 MBytes 145 Mbits/sec
[ 4] 2.00-3.00 sec 17.4 MBytes 146 Mbits/sec
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10
Connecting to host 192.168.0.10, port 5201
[ 4] local 192.168.1.162 port 51720 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 16.7 MBytes 140 Mbits/sec
[ 4] 1.00-2.00 sec 16.5 MBytes 139 Mbits/sec
[ 4] 2.00-3.00 sec 16.4 MBytes 137 Mbits/sec
=============
18.06.4 for HH5A for reference
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[ 4] local 192.168.1.162 port 51757 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 9.41 MBytes 78.8 Mbits/sec
[ 4] 1.00-2.00 sec 8.35 MBytes 70.0 Mbits/sec
[ 4] 2.00-3.00 sec 9.34 MBytes 78.5 Mbits/sec
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10
Connecting to host 192.168.0.10, port 5201
[ 4] local 192.168.1.162 port 51759 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 9.29 MBytes 77.9 Mbits/sec
[ 4] 1.00-2.00 sec 9.23 MBytes 77.4 Mbits/sec
[ 4] 2.00-3.00 sec 9.23 MBytes 77.4 Mbits/sec
19.07-snapshot r10605 for reference.
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[ 4] local 192.168.1.162 port 52587 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.94 MBytes 75.0 Mbits/sec
[ 4] 1.00-2.00 sec 8.84 MBytes 74.1 Mbits/sec
[ 4] 2.00-3.00 sec 8.89 MBytes 74.5 Mbits/sec
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10
Connecting to host 192.168.0.10, port 5201
[ 4] local 192.168.1.162 port 52578 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 8.92 MBytes 74.8 Mbits/sec
[ 4] 1.00-2.00 sec 8.80 MBytes 73.7 Mbits/sec
[ 4] 2.00-3.00 sec 8.86 MBytes 74.4 Mbits/sec
</code>
As far as I remember, all that need to be done to get back the former
lan speed, is to force packet steering to both cores:
**Temporary fix:**
<code>
echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth0/queues/tx-0/xps_cpus
</code>
The same might be true for the wireless interfaces. Changing the values
for vlan or logic interfaces (eth0.x, br-lan) shouldn't have any impact.
The best would be if someone does some more tests to check which values
result in the greatest overall throughput.
Following mkresin's suggestion, here are some test results:
<code>
18.06.4 for HH5A with above **temporary fix** applied via SSH:
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[ 4] local 192.168.1.162 port 51787 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 16.9 MBytes 142 Mbits/sec
[ 4] 1.00-2.00 sec 16.9 MBytes 141 Mbits/sec
[ 4] 2.00-3.00 sec 16.9 MBytes 141 Mbits/sec
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10
Connecting to host 192.168.0.10, port 5201
[ 4] local 192.168.1.162 port 51791 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 16.5 MBytes 138 Mbits/sec
[ 4] 1.01-2.00 sec 16.2 MBytes 136 Mbits/sec
[ 4] 2.00-3.00 sec 16.2 MBytes 136 Mbits/sec
19.07-snapshot r10605 with above temporary fix
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10 -R
Connecting to host 192.168.0.10, port 5201
Reverse mode, remote host 192.168.0.10 is sending
[ 4] local 192.168.1.162 port 52603 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 16.2 MBytes 136 Mbits/sec
[ 4] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec
[ 4] 2.00-3.00 sec 16.2 MBytes 136 Mbits/sec
C:\install\iperf>iperf3 -c 192.168.0.10 -t 10
Connecting to host 192.168.0.10, port 5201
[ 4] local 192.168.1.162 port 52607 connected to 192.168.0.10 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 12.1 MBytes 101 Mbits/sec
[ 4] 1.00-2.00 sec 12.1 MBytes 101 Mbits/sec
[ 4] 2.00-3.00 sec 12.0 MBytes 101 Mbits/sec
</code>