Calling for tests

[Staff 9972]

Hello!

 

We would like to have the help of our fantastic community to determine the optimal value of OpenVPN buffers size in various Operating System on different lines. We have already an opinion and we are aware of some issues with all version of OpenVPN in setting the correct buffer size, which usually result in a too small buffer which causes performance hit on high throughput lines, but your help would be invaluable, because it would allow us to collect measurements from a much wider testing systems.

 

All of the above will help us determine the best approach to treat the matter both in the Configuration Generator and in Eddie, and perhaps even in our VPN servers OpenVPN daemons setup.

 

If you wish to take a role in the testings, you can measure performance with various buffer sizes when all other conditions are the same (try to take measurements with the very same speed tests, same machine load, same VPN servers and same configuration - vary only the buffers sizes for each test).

 

In order to test buffer sizes, add the following directives either to your configuration (.ovpn/.conf) OpenVPN file or in the client Custom directive field you can find in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives. After that, make sure to re-start the VPN connection.

 

The syntax is:

sndbuf size_in_bytes

rcvbuf size_in_bytes

 

We ask you to test first without any sndbuf and rcvbuf directive, and then with the following values for size_in_bytes:

65536

131072

262144

524288

 

For example:

sndbuf 131072

rcvbuf 131072

 

In your report, please specify your Operating System exact version, the VPN server(s) you tested with and the nominal peak bandwidth of your line. For the purposes of our test, a test in UDP is enough, but if you wish to add a test also in TCP you're of course welcome. Please test only with 1 Gbit/s servers, do not test with 100 Mbit/s servers.

 

Thanks so much in advance to all who will spend their time to perform the tests!

 

Kind regards

AirVPN Staff

[go558a83nk 362]

The following tests on Asus AC68 with Merlin firmware 378.54alpha4.  This version uses openvpn 2.3.6 with openssl 1.0.2a.  Connected to Singapore server.  My line speed is 35mbit/s.  All speed tests done from same server in Singapore and with UDP 443 tunnel.

 

Note that the system seems to have a narrow range of possible buffers - it won't go low or high, ignoring the custom options I input.  Also, there may be something interesting with using 0 (zero), though it's not as fast as the larger buffer.

 

no buffer options input
send/receive as shown in log 131072
speed 19.34/5.26 mbit/s

buffers set to "0"
send/receive as shown in log 122880
speed 23.49/5.28 mbit/s

buffers set to 65536
actual buffer used as shown in log 131072
no tested because duplicate

buffers set to 262144
actual used as shown in log 245760
speed 27.85/5.25 mbit/s

buffers set to 524288
actual used as shown in log 245760
not tested because duplicate
 

edited to add more info up top.

[FromtheWalls 83]

I performed all the tests on UDP 443, using the Beid server and on a 50/50 fiber line. My operating system is Windows 7 Home Edition, service pack 1. 

 

These are the results of my tests:

 

No buffer

 

Download speed: 26,55 Mbit/s

Upload speed: 40,02 Mbit/s

 

65536 buffer

 

Download speed: 46,15 Mbit/s

Upload speed: 47,97 Mbit/s

 

131072 buffer

 

Download speed: 46,75 Mbit/s

Upload speed: 47,77 Mbit/s

 

262144 buffer

 

Download speed: 46,47 Mbit/s

Upload speed: 48,09 Mbit/s

 

524288 buffer

 

Download speed: 46,74 Mbit/s

Upload speed: 47,93 Mbit/s

 

Now, while testing this I also decided to check a long standing problem I have had with every VPN provider - single thread downloads have been consistently maxing out around 400 kb/s no matter what I have done when connected through UDP, but it has worked through TCP (but that's not an option since I get crap upload with TCP). So I decided to test the same file on the same server I have tested countless times before on multiple VPN's while connected through UDP, it consistently maxing out at 400 kb/s before... and there you go, now i got over 4500 kb/s in speed on it on the first attempt and every attempt after. It has clearly fixed the problem. So basically, through helping out on this, it actually solved an issue that has haunted me for years and no one have suggested trying this solution before. It definitely seems to me like you should integrate a buffer size into Eddie, I am keeping it added manually for now since it kicks ass. It has made an enormous difference for me.

 

Kind regards

[OpenSourcerer 1435]

OS: MS Windows 8.1, last installation of updates 01 June 2015 (important, recommended)

Client: SecurePoint OpenVPN Client v1.0.3

OpenVPN: 2.3.6 x86_64-w64-mingw32 [sSL (OpenSSL)] [LZO] [PKCS11] [iPv6] built on Mar 4 2015

Library versions: OpenSSL 1.0.1l 15 Jan 2015, LZO 2.08

ISP: Deutsche Telekom AG

DL/UL: 5632 /2280 kbit (as shown by router)

Test: speedtest.net, server: LeaseWeb (ping ~25 ms)

Date: 05.06.2015, 07:44 - 08:30 UTC

Server: Velorum, DE

Connection: UDP port 443 [TCP port 443]

- - -

[1] 65536 (default without directives)

Down: 4.29 Mbit

Up: 1.70 Mbit

 

[2] 0 doesn't change default buffer size

 

[3] 65536 would be a triplicate

 

[4] 131072

Down: 4.28 Mbit
Up: 1.67 Mbit

 

[5] 262144

Down: 4.28 Mbit

Up: 1.71 Mbit

 

[6] 524288

Down: 4.29 Mbit

Up: 1.70 Mbit

---

[TCP tests]

 

[1][2][3] 65536

Down: 4.24 Mbit

Up: 1.73 Mbit

 

[4] 131072

Down: 4.24 Mbit

Up: 1.71 Mbit

 

[5] 262144

Down: 4.24 Mbit

Up: 1.54 Mbit

 

[6] 524288

Down: 4.28 Mbit

Up: 1.72 Mbit

---

Conclusion:

According to speedtest.net, it doesn't really matter how big the buffer is - at least for me. With my tiny tiny piece of broadband compared to some others here I cannot really contribute. But I let my internet connection do its best.

Hope that helps in some ways. I doubt it, but.. you never know.

[knighthawk 19]

Windows Sever 2008 r2  Host

Windows Sever 2008 r2 VM (on same host)

Both using Eddy 2.8

FYI... a week or two ago I switch from using no setting in this regard to

524288 for both I have watched my connection fairly closely there are and did some testing with some in-demand torrents.

 

This was done on 250\250 burst to 500\500 line based in Montreal area datacenter  connected to Toronto based AirVPN servers (Rana and Grumium).  Raw connection was via primarily udp 80, (though I did a couple ssl test that didn't seem to do well), Speedtest.net type testings  (to comcast in detroit, Rack&Data in toronto area, and LayeredServer in buffalo,ny, 3x of each  showed a fairly consistent 8-10mb improvement, (actually a little better on the dl side depending on the speedtest host).

 

Also where previously I would get 35mb maybe 40mb in the rare case for a few seconds with torrents, I can now regularly get 40 or 50 (provided there are seeders\leeches to take\give the traffic), it probably would go higher but I have a feeling the particular datacenter where said system is has limiter that's around 50mb per single ip so that what probably stops it around that range (it's an annoying protection system I think they have in place), though I saw it hit 55 for a short period where as in the past I never ever ever ever in 8mo saw it break 43.  If your wondering I get raw line speed when not connected to the vpn in the same tests.

 

I've been thinking about trying larger figures actually, as high as 1048576 but have not done so yet as things seem very stable at the moment. Results from the Host system vs. the hosted vm were not statistically\substantially different.

 

So bottom line I've seen a notable improvement, though it's not that often when I hit that throughput level (40\50)but when I do it seems to allow for higher levels and far more consistent throughput overall. 

 

**This is however with the rolled back 9.0.0.9 tap-adapter, 9.0.0.21 basically just about doesn't function with or without the buffer setting. *

 

 

BTW I had first tried 65k setting for a few days and while I didn't see any large difference and didn't do as extensive testing, the throughput did seem more consistent so even something that low seems to help.

 

I will try and repeat this again in the particularly more useful form you really want during my next maintenance window.

[athelstan 11]

@giganerd

 

Although the OpenVPN manual shows the default values for sndbuf and rcvbuf as 65536 bytes, this is NOT true for Windows - see here:

 

https://community.openvpn.net/openvpn/ticket/461

 

* On Windows, don't setsockopt SO_SNDBUF or SO_RCVBUF by
  default on TCP/UDP socket in light of reports that this
  action can have undesirable global side effects on the
  MTU settings of other adapters.  These parameters can
  still be set, but you need to explicitly specify
  --sndbuf and/or --rcvbuf.

 

When sndbuf and rcvbuf are not set, my OpenVPN log shows
sndbuf 0
rcvbuf 0

 

However, my tests indicated that explicitly setting them to 0 produced better performance <shrug>

 

Overall, the best values for my Win2008R2 VM with limited resources on a 12Mb/s ADSL line to several servers using TCP and UDP are:

 

sndbuf 65536
rcvbuf 65536

 

with bigger buffers showing the same or worse performance.

 

[OpenSourcerer 1435]

I didn't talk about the general default, but my personal default. I think I can consider a value to be a default value for me when it doesn't change if the directives are omitted.

Shows [65536->65536] in the logfile.

[mlp 10]

Some previous data of mine at https://airvpn.org/topic/13652-eddie-udp-443-on-windows-vs-linux/?p=27134

 

Will try to repeat some additional data in the next few days.

[Staff 9972]

Hello,

 

thanks everybody!

 

We opted to force in the new Eddie 2.10.1 Experimental 128 kB size buffers by default. There is a new option that allows the user to select, for each buffer, OpenVPN Default, 8, 16, 32, 64, 128, 256 and 512 kB, in addition of course to the option to edit directives.

 

128 kB size buffers at the moment seem the best compromise between latency (which is not compromised at all) and performance. Only users with slow lines (dial-up or ISDN lines) could probably prefer to set smaller buffers.

 

Kind regards

[tammo 5]

 Just want to say thanks very much @staff and the testers!

I have downloaded the new config files with the new parameters (Rcvbuf 262144; Sndbuf 262144) only now.

I have a 64/5 (Down/Up) Mbit line with Dual Stack Lite, and it seemed to me as the performance had just lately deteriorated (often only about 15-30 Mbit/s)

Now I almost have again fullspeed!

 

Thank you for this excellent service!
 

[flat4 79]

These changes are just for eddie correct? for people using pfsense. opnsense, or whatever they will need to change their configs manually, is this a correct statement?

[zhang888 1066]

These changes are just for eddie correct? for people using pfsense. opnsense, or whatever they will need to change their configs manually, is this a correct statement?

 

When you use Eddie or the config generator the values are there. When you manually set each and every ovpn client option, this has to be added manually.

[bluesjunior 43]

Hi, I usually check the forums every day and saw this thread here this morning. I have recently installed the latest version v2.11.15 and on checking the OVPN Directives today can see that mine is set to Sndbuf 524288 and Rcvbuf 524288. According to a post above the new parameters should be (Rcvbuf 262144; Sndbuf 262144). Should I change mine and if so how do I do that?.