Hi, On Thu, Nov 09, 2017 at 05:19:14PM +0100, Jan Just Keijser wrote: > - without any load the ping times are ~ 7 ms , which is actually quite > good for ADSL > - when I run a long iperf session and then do a ping in the background, > the ping times go up to 800+ ms, then once the iperf is done, the ping > times go down again
It might be worth to experiment with --txqueuelen (on both sides)
or --tcp-queue-limit and --sndbuf (on the side that sends lots of data
into the TCP connection).
--tcp-queue-limit will limit the amount of data OpenVPN will try to
stuff into the TCP session, so will lead to some loss on the TCP-over-
TCP session, which *could* end up in slower sending by the file
transfer (etc.).
--sndbuf will limit the mount of data sitting inside the kernel for
outgoing packets. Reducing this to, say, 16000, will reduce achievable
throughput (because for througput, you want large buffers to really
sustain sending, not having to wait for the app to fill the buffer
while the network is idle), but will also reduce the amount of data
sitting "in front" of your pings -> better RTT.
I'd try "--sndbuf 16000 --tcp-queue-limit 8" for a start (on the sending
side) and see if that makes a noticeable difference. Then start tuning.
> The bad news: that's just the way it is with OpenVPN over TCP, I guess.
> There are no parameters to tweak that would help (--tcp-nodelay makes
> things *worse*, for example).
Never say we have no options to weak things :-) - we have options for
all the things (and even had bugs in --tcp-send-queue... back then, with
<stdbool.h> :-) ).
> I also suspect that you (and I ) are being
> hit with TCP congestion&recovery delays: when the transfer is
> "interrupted" by an ICMP packet then the TCP window is reset to a much
> lower value and the transfer is throttled. This is normal TCP behaviour.
> However, I suspect that this throttling leads to some form of
> TCP-over-TCP congestion which then blows out the entire link, causing
> ping times to go through the roof.
I suspect it's more "all available queues are filled to the upper limit
by the sending TCP-over-TCP, so the ICMP packet has to queue at the back
of this". No QoS of any sort inside an OpenVPN TCP session.
(I'll throw the buzzword "bufferbloat" into the ring as well, which
describes a similar effect of an ADSL line reaching ping times way over
a second if buffers are *too big* and large downloads filling everything)
> The only thing you can do, is to run something like Traffic Control (tc)
> on the link to prioritize low latency traffic compared to bulk
> downloads. If I throttle my iperf session to use 80% of the maximum link
> speed then the ping times remain much lower. When the link is "100%
> full" with TCP traffic then the ping times increase 100fold.
Right. Limiting inside TCP to 80% (or so) of the maximum achievable
limit will make sure the queues are never filling up.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.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
