From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C393C3B2A3 for ; Tue, 25 Apr 2017 14:22:28 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id u65so30140640wmu.1 for ; Tue, 25 Apr 2017 11:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HLFOBsA/hI15WH5nVW1UYvFMSkxpuG1Iy+EMuwm2uD8=; b=elAXBY1i2iiHinEzbRSoLEXZx7h9N51XccRIXAXyhogpCj/fXZt5MrK/IgF6Hd08bB 6LsBVgGHGeODuiazmp/5llinDP6rhGPCRPNIHwv+lt/5R8z+G8wdPw72xCFeDlugADYe 1T1f/qWfHhkyNi0nZn+jGAGowH0SWR+dMghXFIX78Qo8MYHH+cRzH69zZoGJtCsykVD7 kpRYJIDDUGT9isi2zUgYemTnDabmA3ISbCNvCbXozjCkG/7jM40UVqCcJdEWtjPehT5A Qch14oLo8H/r7ykpUxMC4z7OPn9XDOz4DpDmOEnyMAOiirS/7t0uVvz50ZvhRZNJnqUz udGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLFOBsA/hI15WH5nVW1UYvFMSkxpuG1Iy+EMuwm2uD8=; b=YTp8/21KVqKv4NUHJqmFELHbRFUDym0rPlVZEOtUjyia/QTVTRh0Ka5JVs3zkYAqAZ dNbiA+8ZyODa7T78wUhUiO/PFMWYRbxsv3gwCdkFhFF1IJogiBHPP+6gMV1gom3WKZZ2 YGpUdte5uvFi3+BJInHEk9Huk8kCWsfLmE3vtxJErjmO8Fn3/qaB1D47gWzakaaAWEBX s0EDtRixgmfYYZ3Nv9jVDqWN5m6PXhp2Eh8pqVefeIUJQBCshPIRAVm1lCB4CoTksSCa kjf7+E9SiUbr6ZiPrzUDjVk8DuQuVkqYyedqdcgM9PTr8WbA2iVZtx2wd1e7mzNaBiX1 Pb8w== X-Gm-Message-State: AN3rC/6wmyvVQVB1OkjLIhCZ3DD42dRuIGoRd41ow3GYGv/YeZlYZMTx bPaqgbAFexGtwC+6PoT31IHRDfBtjA== X-Received: by 10.80.165.144 with SMTP id a16mr6452129edc.122.1493144547777; Tue, 25 Apr 2017 11:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.59 with HTTP; Tue, 25 Apr 2017 11:22:26 -0700 (PDT) In-Reply-To: <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> From: Dendari Marini Date: Tue, 25 Apr 2017 20:22:26 +0200 Message-ID: To: Andy Furniss Cc: Sebastian Moeller , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=f403045c45885e5fca054e01ce76 Subject: Re: [Cake] Getting Cake to work better with Steam and similar applications X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:22:28 -0000 --f403045c45885e5fca054e01ce76 Content-Type: text/plain; charset=UTF-8 Hello, Some good news and some bad news. The good news is that using switch0 as inbound and pppoe0 as outbound works, and I was able to set up Steam as bulk using the interface on the ER-X (used DSCP 8 and used a custom DPI category). I confirmed this was working by looking at the bulk traffic increasing (using the "tc -s qdisc" command) and by starting another download (Steam gets pretty much nothing in this case). The bad news is this isn't enough to fix my gaming issue (still having ping spikes, latency variation and packet loss), and even using it with Steam configured to use just one connection didn't change much from my previous testing. So I'm really confused :\ What could cause ping spikes in this case (assuming the multiple connections aren't the issue)? On 25 April 2017 at 14:58, Andy Furniss wrote: > Dendari Marini wrote: > > Also I have done some more testing, I was able to limit Steam connections >> just to one thanks to some console commands ("@cMaxContentServersToRequest" >> and >> "@cCSClientMaxNumSocketsPerHost") and while the situation improved >> (no more packet loss, latency variation within 10ms, but still seeing >> ping spikes of ~50ms) it's still not what I'd consider ideal, which >> would be like with any other download. So my guess is there's >> something else going on other than just the multiple connections, >> which are definitely big part of the problem but not the only thing. >> >> Anyway these are my current settings for Cake and I've been using them >> for the last four days without issues: >> >> *qdisc cake 8005: root refcnt 2 bandwidth 950Kbit diffserv3 >> triple-isolate nat wash rtt 100.0ms atm overhead 40 via-ethernet* *qdisc >> cake 8006: root refcnt 2 bandwidth 17500Kbit diffserv3 triple-isolate nat >> wash ingress rtt 100.0ms atm overhead 40 via-ethernet* >> > > I still think that once via-ethernet appears you really need the raw > parameter. On egress ppp it likely subtracts 22 bytes on ifb that is > attached to ingress ppp 14 bytes. > If you shape on real eth (eg. lan side) or ifb hooked from real eth then > you shouldn't use raw. > > Thinking about it, mostly you will luck into it not making any > difference, so the test I suggested earlier won't work. The reason being > that whether the overhead is 40 or 40 - 22 an MTU sized packet or an > empty ack/single sack will end up the same due to atm. sack > 1 will be > wrong as of course will be other traffic of certain sizes, so a > carefully crafted test would be needed to show the issue. > > Talking of acks/sacks 17500 vs 950kbit doesn't even have room for one > sack per packet, though mostly there will be < 1 ack per packet. > > Depending on your sync rate 17500 may be too close for ingress. > --f403045c45885e5fca054e01ce76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Some good news and some bad news= .

The good news is that using switch0 as inbound a= nd pppoe0 as outbound works, and I was able to set up Steam as bulk using t= he interface on the ER-X (used DSCP 8 and used a custom DPI category). I co= nfirmed this was working by looking at the bulk traffic increasing (using t= he "tc -s qdisc" command) and by starting another download (Steam= gets pretty much nothing in this case).

The bad n= ews is this isn't enough to fix my gaming issue (still having ping spik= es, latency variation and packet loss), and even using it with Steam config= ured to use just one connection didn't change much from my previous tes= ting.

So I'm =C2=A0really confused :\=C2=A0
What could cause ping spikes in this case (assuming the multiple co= nnections aren't the issue)?=C2=A0

=
On 25 April 2017 at 14:58, Andy Furniss <adf.= lists@gmail.com> wrote:
Den= dari Marini wrote:

Also I have done some more testing, I was able to limit Steam connections j= ust to one thanks to some console commands ("@cMaxContentServersToRequ= est" and
"@cCSClientMaxNumSocketsPerHost") and while the situation im= proved
(no more packet loss, latency variation within 10ms, but still seeing
ping spikes of ~50ms) it's still not what I'd consider ideal, which=
would be like with any other download. So my guess is there's
something else going on other than just the multiple connections,
which are definitely big part of the problem but not the only thing.

Anyway these are my current settings for Cake and I've been using them = for the last four days without issues:

 *qdisc cake 8005: root refcnt 2 bandwidth 950Kbit diffserv3 triple-isolate = nat wash rtt 100.0ms atm overhead 40 via-ethernet* *qdisc cake 8006: root r= efcnt 2 bandwidth 17500Kbit diffserv3 triple-isolate nat wash ingress rtt 1= 00.0ms atm overhead 40 via-ethernet*

I still think that once via-ethernet appears you really need the raw
parameter. On egress ppp it likely subtracts 22 bytes on ifb that is
attached to ingress ppp 14 bytes.
If you shape on real eth (eg. lan side) or ifb hooked from real eth then you shouldn't use raw.

Thinking about it, mostly you will luck into it not making any
difference, so the test I suggested earlier won't work. The reason bein= g
that whether the overhead is 40 or 40 - 22 an MTU sized packet or an
empty ack/single sack will end up the same due to atm. sack > 1 will be<= br> wrong as of course will be other traffic of certain sizes, so a
carefully crafted test would be needed to show the issue.

Talking of acks/sacks 17500 vs 950kbit doesn't even have room for one sack per packet, though mostly there will be < 1 ack per packet.

Depending on your sync rate 17500 may be too close for ingress.

--f403045c45885e5fca054e01ce76--