On 08.06.2018 18:47, David Sommerseth wrote:
First of all, IIRC, the default iperf3 runs uses TCP. Your VPN tunnel runs
over UDP (which normally is good). So you're comparing a little bit apples
and oranges here.
No, I compare oranges with oranges: how fast will work application
protocols if OpenVPN is used or OpenVPN not used for network layer.
Just to clarify my statement with comparing appels and oranges.
You needed to be sure that the raw link between client and server behaves
identical with TCP and UDP. Running raw TCP test between end points and
running encrypted and tunnelled TCP packets inside UDP packets over the same
link is considerably different.
Ok, got it! Thank you for detailed explanation!
BTW, when testing iperf3 -c vpn.privacyguard.io --udp --bandwidth 100M
I see 20% packet loss, probably this is the root cause of my problem?
# iperf3 -c vpn.privacyguard.io --udp --bandwidth 100M
[ ID] Interval Transfer Bandwidth Jitter
Lost/Total Datagrams
[ 4] 0.00-10.00 sec 118 MBytes 99.1 Mbits/sec 0.074 ms
16677/85507 (20%)
[ 4] Sent 85507 datagrams
If used with --bandwidth 90M I see 12% of lost Datagrams
Even with --bandwidth 80M I see 2.1% of lost Datagrams
Switch --bandwidth 70M provides 0.027% of lost Datagrams
And only swith --bandwidth 60M provides 0% lost Datagrams
========================================================================
As I understand - this is rate limiting of UDP packets inside OVH.
Also I test from dedicated server inside OVH with 500MBit/sec bandwidth:
test between OVH(500MBit/sec) <=> OVH(100MBit/sec), % Datagrams loss:
100M (26%)
90M (17%)
80M (8.6%)
70M (1.2%)
60M (1.2%)
And also I test between two dedicated servers located inside Hetzner:
test between Hetzner(1GBit/sec) <=> Hetzner(1GBit/sec) % Datagrams loss:
200M (0.41%)
100M (0.41%)
90M (0.019%)
80M (0.083%)
70M (0.21%)
60M (0.37%)
Try running the same iperf3 test outside the VPN tunnel with --udp.
Does that give different results?
Yes, I see Bandwidth 99.1 Mbits/sec and Bandwidth 99.0 Mbits/sec
But I need to see the same excellent values for TCP protocol too.
Quick (hacky) fix is to try using OpenVPN with TCP.
As I understand, this is the only possible workaround
if I want to use OVH as hosting provider for OpenVPN server.
What can be tuned in OpenVPN or in operating system?
As mentioned try using --proto tcp. This is normally not optimal,
but sometimes works better than udp.
Far better:
]# iperf3 -c 172.31.254.1
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 113 MBytes 94.4 Mbits/sec 1233
sender
[ 4] 0.00-10.00 sec 111 MBytes 93.1 Mbits/sec
receiver
David, Thank you very much!
Now my issue is really solved by this TCP mode workaround.
Can I provide feature request for OpenVPN ?
As we can see, iperf3 can detect % of lost Datagrams.
So, OpenVPN can detect % of lost Datagrams too.
And, if OpenVPN see high % of lost Datagrams
it can print WARNING to log file with url pointing
to OpenVPN wiki with detailed explanation of problem.
For example:
WARNING: 12% of lost Datagrams detected, see
https://community.openvpn.net/openvpn/wiki/LostDatagrams for detais.
Or this feature will add processor or network overhead,
and therefore can't be implemented in OpenVPN ?
P.S.
As I read in OpenVPN documentation, --tls-auth option is allowed
in tcp mode but totally useless and provides only overhead
and should be always turned off if OpenVPN work in TCP mode?
Option --tcp-nodelay is good thing for OpenVPN server in TCP mode,
and should always be turned on?
I can't understand what I should do with option --compress lz4
- turn it on, or turn compression completely for lower CPU usage?
As I understand --compress lz4 will work for both, TCP and UDP modes.
Bandwidth on server limited to 100 MBit/sec, so probably
it is better to turn on this feature for OpenVPN in TCP mode?
BTW, if I enable "compress lz4" only in server config
I can see in client error log such misleading message:
Fri Jun 8 23:23:30 2018 us=568487 WARNING: 'comp-lzo' is present in
remote config but missing in local config, remote='comp-lzo'
Probably this is bug in OpenVPN ?
And message should say about 'compress lz4' ?
After enabling 'compress lz4' CPU utilization grow from 10% to 60%.
But bandwidth 100MBit/sec on OpenVPN server is used 100%,
so no more CPU power is needed and 'compress lz4' safely can be enabled.
I suppose what 'compress lz4' should be enabled in my case.
--
Best regards,
Gena
------------------------------------------------------------------------------
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
