Openvpn low performance on Rock64 with Armbian Stretch

[2rl]

Hi! I'm trying to create a vpn access point with a Rock64. I'm receving a low speeds with openvpn but the openssl tests show that there is crypto acceleration. I'm new to all of this. I assume the vpn speeds would be much higher since crypto extensions are enabled in armbian, that's why I choose the Rock64 and Armbian. This is the openssl test: 

openssl speed -evp aes-256-cbc
Doing aes-256-cbc for 3s on 16 size blocks: 14416568 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 10625804 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 4907054 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 1594735 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 218375 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16384 size blocks: 109757 aes-256-cbc's in 3.00s
OpenSSL 1.1.0f  25 May 2017
built on: reproducible build, date unspecified
options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) 
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" 
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc      76888.36k   226683.82k   418735.27k   544336.21k   596309.33k   599419.56k

My internet speed is around 76 MB download and 19 MB upload. The rock64 without a vpn connection is capable of reaching those speeds but with the openvpn connected and using the same cipher aes-256-cbc these are the results: 

speedtest-cli
Retrieving speedtest.net configuration...
Testing from Zare (185.44.76.118)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by fdcservers.net (London) [0.96 km]: 38.804 ms
Testing download speed................................................................................
Download: 20.42 Mbit/s
Testing upload speed....................................................................................................
Upload: 17.88 Mbit/s

I've been reading posts from other people talking about speeds of 60 or 80 MB/s through openvpn connections. Is 20MB the maximum speed I will achieve with the Rock64? If not, what should I do?

 

As I said, I'm new to this and I don't know how to proceed, my ideas are that perhaps openvpn is not compiled to use the crypto engine but maybe I'm just talking nonsense. I'm using Armbian Stretch with desktop legacy kernel 4.4.y

 

Thank you very much for your help 

[tkaiser]

Can you provide output from these two commands one time with VPN active, the other without?

nohup iostat 5 & ; time speedtest-cli ; pkill iostat
ping -c 5 185.44.76.118

(replace '185.44.76.118' with the address shown by speedtest-cli before). A file called nohup.out will be created. Please post the contents as well.

[jmandawg]

I would use something a little more reliable than speedtest.net, try using curl.

 

Here are my results using my renegade (almost same hw as rock64):

 

Without vpn (direct connection):

root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  812M  100  812M    0     0  2948k      0  0:04:41  0:04:41 --:--:-- 4202k

With openvpn:

root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  812M  100  812M    0     0  1758k      0  0:07:52  0:07:52 --:--:-- 1856k

This is using windscribe vpn.  I think the only way to truly test openvpn speed would be on your internal network.  I may try it when i have time.

[tkaiser]

3 minutes ago, jmandawg said:

I think the only way to truly test openvpn speed would be on your internal network

 

But if the use case is called 'accessing the Internet' how should this test relate to reality?

 

You get low download bandwidth 'from the Internet' if roundtrip times are too high. That's why I was asking for ping output. There's a relationship between latency and bandwidth most Internet users are not aware of.

[jmandawg]

I'm not the OP but i'm getting the same types of speed as him, here is the output of the command:

 

root@renegade:/mnt/data# (nohup iostat 5 &) ; time python3 speedtest.py ; pkill iostat
nohup: appending output to 'nohup.out'
Retrieving speedtest.net configuration...
Testing from M247 Europe SRL (185.232.22.136)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Optimum Online (New York City, NY) [0.97 km]: 85.704 ms
Testing download speed................................................................................
Download: 21.54 Mbit/s
Testing upload speed......................................................................................................
Upload: 7.50 Mbit/s

real	0m30.789s
user	0m4.183s
sys	0m1.082s
root@renegade:/mnt/data# ping -c 5 185.232.22.136
PING 185.232.22.136 (185.232.22.136) 56(84) bytes of data.
64 bytes from 185.232.22.136: icmp_seq=1 ttl=64 time=45.0 ms
64 bytes from 185.232.22.136: icmp_seq=2 ttl=64 time=45.0 ms
64 bytes from 185.232.22.136: icmp_seq=3 ttl=64 time=55.6 ms
64 bytes from 185.232.22.136: icmp_seq=4 ttl=64 time=44.3 ms
64 bytes from 185.232.22.136: icmp_seq=5 ttl=64 time=52.1 ms

--- 185.232.22.136 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 44.370/48.444/55.608/4.577 ms
root@renegade:/mnt/data# cat nohup.out 
Linux 4.4.138-rk3328 (renegade) 	09/14/2018 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.46    0.00    0.57    0.18    0.00   97.79

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.05         1.38         0.30    1683297     372672
sda               1.74        53.31        42.73   65187331   52244848

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.81    0.00    0.50    0.00    0.00   97.69

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               1.00        11.20         4.80         56         24

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.81    0.00    0.60    2.36    0.00   95.23

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               2.20        25.60        12.80        128         64

Linux 4.4.138-rk3328 (renegade) 	09/14/2018 	_aarch64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.46    0.00    0.57    0.18    0.00   97.79

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.05         1.38         0.30    1683653     372672
sda               1.74        53.31        42.72   65189319   52245796

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.30    0.00    1.06    0.00    0.00   90.64

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               1.00        20.80         0.00        104          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.78    0.00    6.93    0.35    0.00   85.93

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.20         1.60         0.00          8          0
sda               2.00        21.60         5.60        108         28

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.64    0.00    7.14    0.35    0.00   85.87

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               1.00        13.60         8.00         68         40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.07    0.00    4.00    0.30    0.00   90.63

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               1.20        17.60         2.40         88         12

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.10    0.00    3.71    0.36    0.00   92.83

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               0.40         0.00         2.40          0         12

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.32    0.00    1.82    0.35    0.00   95.51

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mmcblk1           0.00         0.00         0.00          0          0
sda               1.00        13.60         2.40         68         12

root@renegade:/mnt/data# 

 

Here are my speed w/o open vpn:

root@renegade:/mnt/data# python3 speedtest.py Retrieving speedtest.net configuration...
Testing from REMOVED (xx.xx.xxx.xxx)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by <REMOVED> [26.96 km]: 27.688 ms
Testing download speed................................................................................
Download: 110.04 Mbit/s
Testing upload speed......................................................................................................
Upload: 7.74 Mbit/s

 

 

[jmandawg]

Another comparison:

 

Desktop PC over vpn:

$ python3 speedtest.py 
Retrieving speedtest.net configuration...
Testing from QuadraNet Enterprises LLC (173.44.36.71)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Comcast (Miami, FL) [4.24 km]: 66.318 ms
Testing download speed................................................................................
Download: 94.07 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.90 Mbit/s

Renegade over vpn:

root@renegade:/mnt/data# python3 speedtest.py 
Retrieving speedtest.net configuration...
Testing from QuadraNet Enterprises LLC (173.44.36.69)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Comcast (Miami, FL) [4.24 km]: 72.5 ms
Testing download speed................................................................................
Download: 21.30 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.33 Mbit/s

 

[root]

OpenVPN is dated. It is single-threaded and userspace (so no taking advantage of multiple cores and wasting a lot of CPU time switching back and forth between kernelspace and userspace).

If you want a fast VPN on low-clock CPUs (so excluding the likes of i3/i5/i7, where the single core speed is sufficient), the solution you are looking for is Wireguard. Or possibly IPSec, which I haven't tested, but heard of being a pain to configure.

Some speed tests I did a year ago:

I was able to max out the Tinkerboard (RK3288) at about 650 Mbps with Wireguard in the meanwhile. As I upgraded my connection to gigabit fiber, I ended up getting a Zotac box with 2x LAN ports and a Celeron N series CPU, which does 900 Mbps easily.

You have a brief tutorial on setting up Wireguard in that thread - or you can use one of the alternate sources in the Internet.

[jmandawg]

Thanks for the suggestion but my vpn provider doesn't support wireguard yet.

[root]

Then choose a new one :). 

Or set up a VPS "near" (latency-wise) your provider which you can use as an intermediate Wireguard hop and do OpenVPN from that VPS to the provider.

 

If you want more speed out of OpenVPN, the only choice is a better CPU. The performance scales pretty much linearly. 

Before Wireguard, I had a dual setup: OpenVPN set on the router (which was effectively capping all my "default" outgoing connections to ~25 Mbps) and then individual OpenVPN clients on the high-speed devices (desktops/laptops) which could take advantage of the faster CPU.

That assuming your provider permits parallel connections and that you can set up proper exclusions at router level so that outgoing connections from the LAN to the VPN provider do NOT go through the default connection (so you don't do "VPN inside VPN", but rather through the public (ISP) gateway.

[jmandawg]

I don't think the tinkerboard has hardware crypto.  I think the VPN connection should be a lot faster with the RK3288 hardware crypto.

[tkaiser]

6 hours ago, root said:

If you want more speed out of OpenVPN, the only choice is a better CPU. The performance scales pretty much linearly.

 

That's why I asket for the iostat 5 output. This is what happened in @jmandawg's test:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.46    0.00    0.57    0.18    0.00   97.79
           1.81    0.00    0.50    0.00    0.00   97.69
           1.81    0.00    0.60    2.36    0.00   95.23
           1.46    0.00    0.57    0.18    0.00   97.79
           8.30    0.00    1.06    0.00    0.00   90.64
           6.78    0.00    6.93    0.35    0.00   85.93
           6.64    0.00    7.14    0.35    0.00   85.87
           5.07    0.00    4.00    0.30    0.00   90.63
           3.10    0.00    3.71    0.36    0.00   92.83
           2.32    0.00    1.82    0.35    0.00   95.51

Not a general CPU bottleneck to spot but of course switching back and force between userspace and kernel.

[TonyMac32]

10 hours ago, jmandawg said:

I don't think the tinkerboard has hardware crypto

Yes it does, and it's enabled.

[jmandawg]

So I ended up isolating cpu core 2 in systemd so that the only thing that runs on it is openvpn, and confirmed in htop.  Now i'm getting much better performance but it flucuates ALOT depending on which server i get connected to (between 30mbs and 70mbps).  I don't know how accurate the speedtest-cli is compared to just downloading a file.  Hopefully WIndscribe starts supporting wireguard soon.  Hopefully this helps the OP.

 

root@renegade:/mnt/data# python3 speedtest.py 
Retrieving speedtest.net configuration...
Testing from QuadraNet Enterprises LLC (167.160.172.18)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Windstream (Chicago, IL) [2.57 km]: 79.21 ms
Testing download speed................................................................................
Download: 68.82 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.80 Mbit/s

 

Modify /etc/systemd/system.conf

uncomment the CPUAffinity line and set it to use cores 0 1 3

CPUAffinity=0 1 3

Modify /etc/systemd/system/openvpn.service

add the CPUAffinity line under [service] and set it to use core 2

[Service]
CPUAffinity=2

 

Finally reboot

 

[root]

Try iperf3 instead - I found speedtest results to vary greatly (even when testing against the same server, which can be specified in the command line) for no apparent reason.

Some public servers are listed at https://iperf.fr/iperf-servers.php.

 

[jmandawg]

Thanks, I think there are too many variables at play using the Windscribe servers, as even the iperf3 results vary from 20-60Mps...

 

 

[2rl]

4 hours ago, jmandawg said:

So I ended up isolating cpu core 2 in systemd so that the only thing that runs on it is openvpn, and confirmed in htop.  Now i'm getting much better performance but it flucuates ALOT depending on which server i get connected to (between 30mbs and 70mbps).  I don't know how accurate the speedtest-cli is compared to just downloading a file.  Hopefully WIndscribe starts supporting wireguard soon.  Hopefully this helps the OP.

 

root@renegade:/mnt/data# python3 speedtest.py 
Retrieving speedtest.net configuration...
Testing from QuadraNet Enterprises LLC (167.160.172.18)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Windstream (Chicago, IL) [2.57 km]: 79.21 ms
Testing download speed................................................................................
Download: 68.82 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.80 Mbit/s

 

Modify /etc/systemd/system.conf

uncomment the CPUAffinity line and set it to use cores 0 1 3

CPUAffinity=0 1 3

Modify /etc/systemd/system/openvpn.service

add the CPUAffinity line under [service] and set it to use core 2

[Service]
CPUAffinity=2

 

Finally reboot

 

 

I've done what you suggested and the result has dramatically improved the speed: from 21 mbit/s to 50-55mbit/s

I thought that by having the crypto extensions enabled in ARMv8 the performance of Openvpn would automatically rocket compared to the raspberry pi for instance without need to alter anything.

 

 

On 9/14/2018 at 6:58 PM, tkaiser said:

Can you provide output from these two commands one time with VPN active, the other without?

nohup iostat 5 & ; time speedtest-cli ; pkill iostat
ping -c 5 185.44.76.118

(replace '185.44.76.118' with the address shown by speedtest-cli before). A file called nohup.out will be created. Please post the contents as well.

 

This the output, I've noticed that the ping is 55% higher through connections from the Rock64 than from my laptop, that could be interfering with the speed:

WITH VPN AND CORE 2 ISOLATED FOR OPENVPN_____________ Linux 4.4.152-rockchip64 (rock64)       09/15/2018      _aarch64_       (4 CP$

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.28    0.00    0.25    0.02    0.00   99.45

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mtdblock0         0.00         0.01         0.00        108          0
mmcblk1           0.39        16.28         0.22     242009       3240
zram0             0.11         0.05         0.38        736       5584
zram1             0.02         0.08         0.00       1196          4
zram2             0.02         0.08         0.00       1196          4
zram3             0.02         0.08         0.00       1196          4
zram4             0.02         0.08         0.00       1196          4

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11.94    0.00    0.70    0.00    0.00   87.36

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mtdblock0         0.00         0.00         0.00          0          0

ping -c 5 185.44.76.118
PING 185.44.76.118 (185.44.76.118) 56(84) bytes of data.
64 bytes from 185.44.76.118: icmp_seq=1 ttl=49 time=25.5 ms
64 bytes from 185.44.76.118: icmp_seq=2 ttl=49 time=24.6 ms
64 bytes from 185.44.76.118: icmp_seq=3 ttl=49 time=24.7 ms
64 bytes from 185.44.76.118: icmp_seq=4 ttl=49 time=26.1 ms
64 bytes from 185.44.76.118: icmp_seq=5 ttl=49 time=24.9 ms

--- 185.44.76.118 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 24.633/25.221/26.146/0.572 ms



WITHOUT VPN AND CORE 2 ISOLATED FOR VPN ------------------------Linux 4.4.152-rockchip64 (rock64)       09/15/2018      _aarch64_       (4 CP$

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.30    0.00    0.27    0.02    0.00   99.42

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mtdblock0         0.00         0.01         0.00        108          0
mmcblk1           0.39        16.06         0.24     242009       3608
zram0             0.10         0.05         0.37        736       5584
zram1             0.02         0.08         0.00       1196          4
zram2             0.02         0.08         0.00       1196          4
zram3             0.02         0.08         0.00       1196          4
zram4             0.02         0.08         0.00       1196          4

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13.59    0.00    2.14    0.00    0.00   84.27

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
mtdblock0         0.00         0.00         0.00          0          0

ping -c 5 86.158.85.129
PING 86.158.85.129 (86.158.85.129) 56(84) bytes of data.
64 bytes from 86.158.85.129: icmp_seq=1 ttl=63 time=2.46 ms
64 bytes from 86.158.85.129: icmp_seq=2 ttl=63 time=6.16 ms
64 bytes from 86.158.85.129: icmp_seq=3 ttl=63 time=2.82 ms
64 bytes from 86.158.85.129: icmp_seq=4 ttl=63 time=6.07 ms
64 bytes from 86.158.85.129: icmp_seq=5 ttl=63 time=4.89 ms

--- 86.158.85.129 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.462/4.484/6.167/1.575 ms

 

 

If there aren't any further improvements that can be implemented to improve the performance of openvpn, I will try to use wireguard, it sounds like the ideal solution for devices like ours.

 

If anyone thinks that the openvpn performance should be better than what we've seen in this post, I'm all ears.

 

Thanks all for your answers

[jmandawg]

I've actully did more test this morning and i'm getting full 100mbs over vpn (with the isolated cpu).  There is probably less traffic on a sunday morning.  Also i think i might be connected to a better server.

when you run your speed test make sure it uses a different core than the openvpn:

 

taskset -c 0 python3 speedtest.py

 

root@renegade:/mnt/data# taskset -c 0 python3 speedtest.py
Retrieving speedtest.net configuration...
Testing from Amanah Tech (104.254.93.181)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Ookla (Toronto, ON) [2.60 km]: 62.424 ms
Testing download speed................................................................................
Download: 95.08 Mbit/s
Testing upload speed......................................................................................................
Upload: 10.55 Mbit/s

 

 

Another option to prevent anything from being scheduled on your openvpn core is to modify the /boot/boot.cmd and add isolcpus=2 to the bootargs (you will still need the CPUAffinity setting in the systemd openvpn.services file to run it on core 2):

 

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs} isolcpus=2"

Then run:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and reboot.

 

 

Let us know what speeds you get from wireguard, i wish my  provider supported it, but you shouldn't have to do any of this crap to get full speed with wireguard.

[root]

Interesting, I wouldn't have thought of this - but it makes sense.

 

With a Tinkerboard, Armbian and Wireguard I was able to get ~600 Mbps from the Tinkerboard to the Internet. I think I tested this up to 750 Mbps in my LAN (desktop to Tinkerboard), but the TB's CPU got really hot (I had to take the cover off in order to keep it running).

Plus - with a single network interface, you're constrained to either an "out of band" gateway setup (the Tinkerboard is just another LAN box and your router provides the Tinkerboard's IP address as the default gateway to the other clients) or you're stuck to the ~250 Mbps that you could get through an USB network adapter (as there's no USB3 on the TB).

[2rl]

Ok, I'm halfway through setting my vpn router, I still need to change the iptables rules so I can access the local network devices through the armbian access point. I've got some interesting results after enabling the access point and routing all my traffic through tun0.

 

My first surprise was that without implementing any of the jmandawg suggestions about isolating core 2, from my laptop. Connected to the ARMBIAN access point and routing the traffic through tun0, I ran speedtest and I got constant speeds of 72mbit/s which is almost the maximum I can reach from my connection, pings were 28ms, the minimum I reach even without the vpn, directly from my router. I'm very pleased with this performance and I wasn't expecting it. 

 

I suppose the fact that the Rock64 only job in this scenario is to encrypt and the run of the tests, web browsing and any other processing is done by my laptop shows the real encrypting potential of the openvpn running in the rock64 without any tweaking.

 

The next step was to test the speedtest from the Rock64 directly, results: 25mbit/s speeds and pings of 40ms. Expected

 

Then I implemented jmandawg suggestions the results from my laptop didn't vary a bit, they were excellent before and stayed the same.

The results from the Rock64 directly varied greatly. When I ran the tests with  "taskset -c 1 speedtest-cli" the results are 68mbit/s and ping 28ms. Same test, this time only "speedtest-cli" and the speed went down to 23mbit/s or maximum 30mbit/s

 

I don't fully understand why if I've isolated a core for openvpn, I still need to isolate another core to run another program in order to achieve good performance with openvpn. Shouldn't it be enough to have core 2 isolated?

 

Another thing is I didn't have "/etc/systemd/system/openvpn.service" The only other place where I found openvpn.service and where I made the changes is "/etc/systemd/system/multi-user.target.wants/openvpn.service" Could this be affecting anything?

 

I don't run my openvpn through the network manager but by the openvpn command

 

  

[sfx2000]

On 9/15/2018 at 5:40 AM, TonyMac32 said:

Yes it does, and it's enabled.

 

Kind of... rk_crypto as a kernel module is built and loaded...

 

Doesn't mean it's all that fast, just saying, but one also has to look at the API's exposed - cryptodev or af_alg for OpenSSL userland - not seeing this at present with the stock packages - yes, there are patches avail for OpenSSL, and most folks on distro's decline to patch it for obvious reasons... one does not play dice with security.

 

Just wandering into this thread as part of a discussion somewhere else about crypto accel on the rockchips - if one looks at openssl as delivered on armbian, the only engine that is avail is "dynamic" - so it's all core there.

 

In any event - max expected potential OVPN thruput on the rk3288-tinker is right around 160 Mb/Sec running on cores as it stands.. it's not low, it's actually pretty good.

 

3200/time = throughput in Mb/Sec

sfx@tinker:~$ openvpn --genkey --secret /tmp/secret
sfx@tinker:~$ time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc
Fri Sep 21 16:19:38 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Real 0m19.924s
user 0m19.858s
sys 0m0.062s
sfx@tinker:~$ openssl engine
(dynamic) Dynamic engine loading support

 

[jmandawg]

What are the results with openssl with the patches applied?

[sfx2000]

6 hours ago, jmandawg said:

What are the results with openssl with the patches applied?

 

It's on my to-do list... I'm not holding for much bigger numbers though - as OpenSSL is only one part of the picture...

 

I've found that some crypto blocks can throw big numbers for kb/sec on openssl speed, but one also needs to keep in mind the number of blocks processed - one has to look at the "Doing <cipher> for 3 s on <x size> blocks: number of <cipher> in <time>" - and sometimes the SW implementation is actually more efficient, the crypto block reduces load on the cores - depends on the platform, but HW accel doesn't always provide faster results, although they may be better overall in a task context...

[jock]

On 9/16/2018 at 2:35 PM, jmandawg said:

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs} isolcpus=2"

Then run:

mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

and reboot.

You're doing it the hard way.

Just add extraargs=isolcpus=2 in /boot/armbianEnv.txt and you're done