Hi, On Fri, Jun 08, 2018 at 02:36:21PM +0300, Gena Makhomed wrote: > > is relevant, because it can show if your ISP is rate-limiting UDP traffic > > (thus killing OpenVPN performance). A number of them do so here in > > Germany, which is very annoying. > > My ISP is not used in tests at all, because I run test between two VPS, > First VPS (iperf3 client) located inside my Hetzner dedicated server > and has network connectivity 1GBit/sec, second VPS (iperf3 server) > located inside OVH "VPS SSD 1" and has network connectivity 100MBit/sec.
And there are no ISPs between Hetzner and OVH...?
> "iperf3 --udp" with and without OpenVPN is near 100 MBit/sec,
> so all is Ok, UDP traffic is not limited at all.
This is an important find: the problem is not "with UDP, outside OpenVPN".
> "iperf3 --tcp without VPN" show speed near 100 MBit/sec:
>
> [ 4] 0.00-10.00 sec 120 MBytes 101 Mbits/sec sender
> [ 4] 0.00-10.00 sec 117 MBytes 98.2 Mbits/sec receiver
>
> "iperf3 --tcp with VPN" show only 29 MBit/sec:
>
> [ 4] 0.00-10.00 sec 34.7 MBytes 29.1 Mbits/sec sender
> [ 4] 0.00-10.00 sec 34.4 MBytes 28.8 Mbits/sec receiver
>
> But if I add swith "--parallel" all works fine:
>
> # iperf3 -c 172.31.254.1 --parallel 8
> [SUM] 0.00-10.00 sec 107 MBytes 90.1 Mbits/sec sender
> [SUM] 0.00-10.00 sec 105 MBytes 88.4 Mbits/sec receiver
>
> # iperf3 -c 172.31.254.1 --parallel 8 --reverse
> [SUM] 0.00-10.00 sec 108 MBytes 90.5 Mbits/sec sender
> [SUM] 0.00-10.00 sec 105 MBytes 88.2 Mbits/sec receiver
>
> I can't understand why "iperf3 --tcp without VPN" show 100 MBit/sec,
> but "iperf3 --tcp with VPN" show only 29 MBit/sec.
Latency. I'm surprised it hits that badly, but it is fairly common for
a single TCP stream to be unable to saturate a link if the latency is
high enough - and OpenVPN does add latency.
We have an iperf3 server here that has a 10G Internet link, and I recently
tested to another ISP who has a 100G iperf3 server. With a single TCP
stream (no OpenVPN involved) we max out at about 1 Gbit/s., but with
10 parallel streams it scales up to 7.5 Gbit/s. (at which point one of
the backbone links is full, so "maxing out").
Single-stream TCP performance depends on the length of the session
(slow-start, bandwidth used only slowly ramping up, so measuring more
than 10 seconds might change this), the TCP window size and scaling
(which is very much OS dependent) and also on the TCP algorithms used
- the new BRR stuff is much more aggressive than the old TCP reno etc.
algorithms. It *could* also be a case of packet loss somewhere - as
soon as you hit a single lost packet (e.g. due to "socket buffer on
the tun interface full"), TCP will reduce sending rate significantly
because it assumes "too fast, link full, packet drop".
So, wrapping up: OpenVPN seems to add enough latency *or* packet loss
to kill single-stream TCP performance, but with enough streams, OpenVPN
will keep up, at least with a 100mbit link.
On the openvpn-devel list, there is a discussion thread about OpenVPN
on 1G and 10G links, with more or less latency, and we do not have a
proper conclusion yet on "what is causing <x>"...
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
