OpenVPN performance

[bilboSNB]

Can anyone say how the ac87u performs with regards to openvpn?

I am thinking of upgrading my n66u and am contemplating this or the ac68u.

 

[cosmoxl]

Can anyone say how the ac87u performs with regards to openvpn?

I am thinking of upgrading my n66u and am contemplating this or the ac68u.

the ac68 is nice but the ac87 is even faster, on paper.

 

[ika]

age isn't the issue. the CPU architecture is what drives openvpn potential. I think the AC66 is a MIPS architecture, while the AC56 is ARM. am I right?

yes, and the ARM in the ac56 is a much faster CPU, especially when it comes to calculations involving floating points.

 

[hytekj]

yes, and the ARM in the ac56 is a much faster CPU, especially when it comes to calculations involving floating points.

Good to know. I guess I will be shopping for a new router. Question is if I should get the 68U or 87U. I am still interested if anyone has a guide for configuring all the following options to get best performance: compression/mssfix/mtu/fragment/float ?

 

[watusi]

Can anyone say how the ac87u performs with regards to openvpn?

I am thinking of upgrading my n66u and am contemplating this or the ac68u.

I did some tests just yesterday, but I do not think I can trust the results. There is something funny going on, and I saw some test results with Private Tunnel nodes that exceed my Internet bandwidth.

Specifically, I saw a results with Speedtest.net of 320mbps. That's impossible - my service is capped at 100mbps with burst to 150.

Other than that, I saw rational results, but - that I cannot trust due to the above!

Note that the test above doesn't involve the router at all - it was just a test of TunnelBlick on my Mac connecting to Private Tunnel nodes.

I did do a realistic test by taking my MacBook and iPad Air2 to a friend's house, though. I'm afraid I forgot to test with my iPhone 5S. The Air2 was no slower than the MacBook, though. I have OpenVPN set-up on my router.

My service: 100mbps down/burst to 150. 10 mbps up, burst to 20.

Friend's service: 32mbps down/5mbps up (should burst, but didn't observe that, I think his provisioning is screwed up! Same cable system, different node.)

I can pretty-much max-out my uplink bandwidth, and clearly can max-out his.

I get 8+mbps (closer to 9) when at my friend's house, and routing Internet traffic to exit through my router. I get very nearly 5 on upload, so max's out my friend's uplink bandwidth.

I might go to "Ultimate" service, which is 150mbps down, burst to 180, and 20mbps up (I think burst to 30 or so.) and see if I get > 10 or if the AC87 is the limitation.

Definitely much better than my DIR-825 in any case, though I am comparing apples and oranges. The DIR-825 was set-up with IPSec, and I was only ever able to get iPhone/iPad to work, never did figure out MacBook setup.

FWIW, private tunnel is good enough to watch HD on BBC iPlayer from California through privatetunnel's London node. In OS X Yosemite, browse to the iPlayer site, start HD playback, then maximize the browser to distraction-free full-screen mode. Now, AirPlay to Apple TV, and you will get HD video on your TV.

Not that I would encourage anybody to do that... I just tried it to see if it would work.

I got private tunnel as an option for secure Internet at Starbucks or a hotel room. I think my home router setup is good enough, though, but private tunnel gives me another option if that isn't working and I just need Internet access and don't need access to my home network. And, as a developer, it is interesting/useful to be able to pop-out on the net in different parts of the world for diagnostics and to see regional differences in sites, etc.

Again, above is just Mac using TunnelBlick, but you can also use the router's OpenVPN client to do similar for your entire local network.

The anomalous double-speed report using private tunnel suggests that there is something strange going on that makes SpeedTest not an accurate test for OpenVPN. I'm guessing that their test data might be compressible.

 

[hytekj]

Good to know. I guess I will be shopping for a new router. Question is if I should get the 68U or 87U. I am still interested if anyone has a guide for configuring all the following options to get best performance: compression/mssfix/mtu/fragment/float ?

So I replaced my 66 with a 68 and the speed is a bit improved - 7mbps down and 4mbps up. My home internet is 200/20 and my 4G is testing in at 15/13 so there is still speed improvement desired. Can anyone help me with my configuration based on my earlier posts? Specifically, mssfix/mtu/fragment/float? Thanks!

 

[somms]

So I replaced my 66 with a 68 and the speed is a bit improved - 7mbps down and 4mbps up. My home internet is 200/20 and my 4G is testing in at 15/13 so there is still speed improvement desired. Can anyone help me with my configuration based on my earlier posts? Specifically, mssfix/mtu/fragment/float? Thanks!

http://forums.smallnetbuilder.com/showthread.php?p=155725#post155725

Posted earlier my OpenVPN throughput on a R7000 running Shibby's Tomato-ARM v124 w/OpenVPN 2.3.6:

Above OpenVPN w/Protocol TCP...

Above OpenVPN w/Protocol UDP...

Above is my typical FTTH symmetrical throughput...

 

[magicool]

Any updates? I have the same problem with the OpenVPN server running on my ac68u, latest Merlin firmware. Using a 100/100mbps connection on both sides I get approx. 25mbps speed, one CPU core is at 60% and the second is at 0% usage.

I did a test to make sure its not a bandwidth problem: OpenVPN server running on Debian = approx. 60mbps speed (limited by the cpu core running at almost 100%)

 

[BWR]

My OpenVPN link on an AC86U (default CPU speed, no overclocking) caps at 2MB/s, with one core at full-load and the other one idle.

 

[cosmoxl]

My OpenVPN link on an AC86U (default CPU speed, no overclocking) caps at 2MB/s, with one core at full-load and the other one idle.

do you mean AC68U?

It sounds like you are using openvpn client 1. Try using client 2.

When using client 1, only core 1 is used because openvpn and the regular routing the router does is all done on core 1. When using client 2, openvpn will run on core 2. With the major operations divided this may increase your speed a little bit.

 

[RMerlin]

do you mean AC68U?

It sounds like you are using openvpn client 1. Try using client 2.

When using client 1, only core 1 is used because openvpn and the regular routing the router does is all done on core 1. When using client 2, openvpn will run on core 2. With the major operations divided this may increase your speed a little bit.

Actually it's the opposite. I specifically swapped them for this very reason

 

[magicool]

I overclocked the CPU to 1100mhz. It shows great speed improvement on openssl speed benchmark aes-128 cbc, but the speed is still capped at approx. 25mbps
So it is not limited by CPU or bandwidth.

What else could it be?

 

[hytekj]

I am still trying to find a tutorial or how-to on configuring mssfix/mtu/fragment/float/etc. I switched from 66>68 because of the CPU but still seeing some speed limitations. Others are posting they are easily able to get 20mbps out of the router.

 

[cosmoxl]

I can get 35mbps, which is my ISP max, with my AC68. but, it also depends on your VPN provider.

try these all at the same time.

mssfix 0
mtu-disc yes
fast-io

 

[BWR]

do you mean AC68U?

Yes, sorry for the typo.

It sounds like you are using openvpn client 1. Try using client 2.

When using client 1, only core 1 is used because openvpn and the regular routing the router does is all done on core 1. When using client 2, openvpn will run on core 2. With the major operations divided this may increase your speed a little bit.

Actually it's the opposite. I specifically swapped them for this very reason

RMerlin, which firmware version was this implemented in? Using latest @john9527's fork, OpenVPN server1 is using the first core (as seen in top), which has high softirq usage as well. A snapshot of top during a speedtest.net run:

CPU0: 40.1% usr 22.5% sys  0.0% nic  0.0% idle  0.0% io  0.0% irq 37.2% sirq
CPU1:  0.0% usr  2.9% sys  0.0% nic 96.0% idle  0.0% io  0.0% irq  0.9% sirq

11769     1 admin    R     4112  1.6   0 49.4 /etc/openvpn/vpnserver1 --cd /etc/openvpn/server1 --config config.ovpn

To me, it looks like the OpenVPN server performance is limited strictly by the CPU as it's single-threaded only and it saturates the core it's running on. Couldn't it be compiled with multi-threading support?

L.E. Nevermind, seems like OpenVPN itself lacks support for multi-threading: http://community.openvpn.net/openvpn/wiki/RoadMap#Threading
So that's that, the only way to add more juice into it is by either going with a more powerful router or overclocking your existing one.

 

[RMerlin]

RMerlin, which firmware version was this implemented in? Using latest @john9527's fork, OpenVPN server1 is using the first core (as seen in top), which has high softirq usage as well. A snapshot of top during a speedtest.net run:

The sirq usage comes from the network driver and the rest of the kernel, not from the OpenVPN process, which only handles encryption and basic protocol functionality.

 

[john9527]

RMerlin, which firmware version was this implemented in? Using latest @john9527's fork, OpenVPN server1 is using the first core (as seen in top), which has high softirq usage as well. A snapshot of top during a speedtest.net run:

I'll see if I can track it down.

 

[manaox2]

Consider repurposing an old PC as a pfSense box. Works like a charm.

 

[john9527]

RMerlin, which firmware version was this implemented in? Using latest @john9527's fork, OpenVPN server1 is using the first core (as seen in top), which has high softirq usage as well. A snapshot of top during a speedtest.net run:

CPU0: 40.1% usr 22.5% sys  0.0% nic  0.0% idle  0.0% io  0.0% irq 37.2% sirq
CPU1:  0.0% usr  2.9% sys  0.0% nic 96.0% idle  0.0% io  0.0% irq  0.9% sirq

Thank you for your powers of observation! Tracked down the code and somewhere way back when a logic bug must have slipped in on both server and client (CPU assignment was reversed, instance 1 always to CPU0, instance 2 always to CPU1).

(Merlin, the same assignments are also in your latest master, /release/src/router/rc/openvpn.c, line 409 for vpnclient, line 1280 for vpnserver)

Started out with the same CPU usage signature as your example as a VPN Client 1 with VPN active and doing a speedtest at speedtest.net

CPU0: 20.5% usr  7.1% sys  0.0% nic 54.6% idle  0.0% io  0.0% irq 17.5% sirq
CPU1:  0.0% usr  0.7% sys  0.0% nic 97.6% idle  0.0% io  0.0% irq  1.5% sirq

Speedtest results: 31.67 Mb/s Down, 6.42 Mb/s Up
http://www.speedtest.net/my-result/4057018067

With the fix moving OpenVPN client 1 to CPU1

CPU0:  0.0% usr  2.1% sys  0.0% nic 77.8% idle  0.0% io  0.0% irq 20.0% sirq
CPU1: 31.1% usr 10.1% sys  0.0% nic 45.7% idle  0.0% io  0.0% irq 12.9% sirq

Speedtest results: 53.25 Mb/s Down, 6.35 Mb/s Up
http://www.speedtest.net/my-result/4057030768

Needless to say, will be picking this up in the next fork release.

 

[RMerlin]

Thank you for your powers of observation! Tracked down the code and somewhere way back when a logic bug must have slipped in on both server and client (CPU assignment was reversed, instance 1 always to CPU0, instance 2 always to CPU1).

(Merlin, the same assignments are also in your latest master, /release/src/router/rc/openvpn.c, line 409 for vpnclient, line 1280 for vpnserver)

I'll have to recheck. I know at one point Asus removed that code after merging my code into upstream, it's possible that at that point I re-added it incorrectly.