Hi,

On Thu, Nov 9, 2017 at 11:48 AM, Gregory Sloop <gr...@sloop.net> wrote:

> 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.
>

This may be true in many networks but does not look unavoidable.
I have seen the "bufferbloat" -like behaviour that Gert alluded to with many
residential DSL/ADSL providers which got cured as we moved to metro
ethernet--similar bandwidth but no latency spikes under load.

So I do feel that high latency under load is not a fundamental limitation
-- probably
openvpn with --proto tcp is not trying hard to manage the queue smartly?
Whatever
that means...

Selva
------------------------------------------------------------------------------
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

Reply via email to