Top posting
JJK> The only thing you can do, is to run something like Traffic Control (tc)
JJK> on the link to prioritize low latency traffic compared to bulk
JJK> downloads. If I throttle my iperf session to use 80% of the maximum link
JJK> speed then the ping times remain much lower. When the link is "100%
JJK> full" with TCP traffic then the ping times increase 100fold.
While I'm not going to address, specifically, OpenVPN's handling of this - this
is just typical behavior when links get loaded. I run smokeping [with
fping/icmp ping] to monitor a bunch of stuff - especially my client's external
internet connections.
The universal sign of a congested link is latencies going up by, easily, an
order of magnitude, and little or no packet loss. [i.e. 30ms to 300ms, or even
more] Once a connection reaches very high levels of utilization, latencies
increase dramatically.
So, the fact that OpenVPN does similar things seems unremarkable to me.
[But perhaps I missed something more in the thread that does make it more
remarkable...]
HTH
-Greg
JJK> Hi,
JJK> On 09/11/17 11:08, Gof via Openvpn-users wrote:
>>> you're using bridging + tap + proto tcp + port sharing on a VPS and are
>>> expecting good latency? hmmm.... there are many reasons why that combination
>>> will NOT give you any performance.
>> Bridge is used only to link TCP and UDP clients. All client machines are
>> mine and used by me alone, and 99% of the time don't generate any traffic,
>> they're only there so I can log into them. During my tests I used only these
>> two machines I did the test on.
>> Why tap might be a worse idea than tun?
JJK> tap has a slightly higher overhead compared to tun, but it would not
JJK> explain the high latency during a transfer.
>> As to port sharing, I can disable it, but isn't it used only during initial
>> handshake?
>> As to the bridge, TAP and VPS, it performs very well with UDP-connected
>> clients, so I suspect TCP alone...
>>> However, I see an increase in ping time in my setup as well:
>>> - udp
>>> - tun
>> This increase (from 0.6ms to 4ms) is normal and perfectly acceptable... but
>> not to 3000ms, it definitely isn't only encryption/decryption latency...
JJK> as Gert was pointing out already, it's mostly related to the nature of
JJK> TCP traffic.
JJK> The good news is: I can reproduce what you are seeing at home (ADSL) as
JJK> well:
JJK> - I'm connecting to a server at work over TCP
JJK> - without any load the ping times are ~ 7 ms , which is actually quite
JJK> good for ADSL
JJK> - when I run a long iperf session and then do a ping in the background,
JJK> the ping times go up to 800+ ms, then once the iperf is done, the ping
JJK> times go down again
JJK> The bad news: that's just the way it is with OpenVPN over TCP, I guess.
JJK> There are no parameters to tweak that would help (--tcp-nodelay makes
JJK> things *worse*, for example). I also suspect that you (and I ) are being
JJK> hit with TCP congestion&recovery delays: when the transfer is
JJK> "interrupted" by an ICMP packet then the TCP window is reset to a much
JJK> lower value and the transfer is throttled. This is normal TCP behaviour.
JJK> However, I suspect that this throttling leads to some form of
JJK> TCP-over-TCP congestion which then blows out the entire link, causing
JJK> ping times to go through the roof.
JJK> The only thing you can do, is to run something like Traffic Control (tc)
JJK> on the link to prioritize low latency traffic compared to bulk
JJK> downloads. If I throttle my iperf session to use 80% of the maximum link
JJK> speed then the ping times remain much lower. When the link is "100%
JJK> full" with TCP traffic then the ping times increase 100fold.
------------------------------------------------------------------------------
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
