From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 8E47E3B2A3 for ; Tue, 25 Apr 2017 17:43:43 -0400 (EDT) Received: from [192.168.1.222] ([80.135.80.149]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lt1S6-1c0cbP2qsM-012Yub; Tue, 25 Apr 2017 23:43:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> Date: Tue, 25 Apr 2017 23:43:40 +0200 Cc: Dendari Marini , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <06A39EE4-4EF5-477B-B737-98195BA5CFAB@gmx.de> 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> To: Andy Furniss X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:IJlnWvLeRmXmSIuNrvE9Mk8KRvbpe38g73q0hsB3845G35qlhN9 TODs000C1z63JN9lCc3DEa2rAH+R5uGgfTwVW4lNPuAoZX/AhKlAXrxakhUT3aKatHNkNuk cdIUdwAB7w+Nf443J7m+8+jLpIq2/ne+jQftRnvT4jVEDnDLHfeMpd56jtSnHwam6PSRO1C 8diXuXbo4C2mdUmuUN37w== X-UI-Out-Filterresults: notjunk:1;V01:K0:zHqQ9g1c4XE=:CkIkYQGR/WXomqw+0LdUGq BDt5eYDMXnX/lc5txI+Sz3CZuyQOgXp5YaxF3NsRQ96aEkVS8YQOLSwV+8MQoz+A+OMRW0Sjj ubQZ5FHTWtnhU1aoC8iDbWrW3AXSpcxj3QmdGM/oPPu/0PktLpsX1WA82vvDaAP1du9DOjSNT wd4JaRMSUz0JtzNUYt1jJwp3EiF6q6Vjhw71KyRyKga2MUQNyeNg0nZ6h/CNl+A2DWADp2NsV bPm1xyz6bNLZ8iSXncSkuYX2yxOoyF2lbSpowPf2hXV42M1HTGMFij4FB73aiCAPJ7zH9s5U/ 1Si4H7N/5lyDqZs8TsvU1A79KPIToLzalHv3l9iyNlMlZmukiQ+PfaL1R+aU7iu5JaUtmaCKL FiJAknrTLQPUF82KR2cwK+mIviujPkIk3TlryWeC98b7bsf8vrvqzDX52Xz2DebeJTqkEIDp2 lJ+A4003bgsQsu/eZVOY22zCGolob0H3Y11o/fsfkrW/Ffcxu4/Jg4i0p/HsP7DS8ze0zXrJN IeY8A1Q5a6bVo5qoMFKTmB6sFrM9LORCHkclMSzcbLuAXVIDiMwYj99SGxKFUNCAfRY0ZKAUU tnBuPZKY9aWZuYYuS894F91lqyZBJzNn9q6KBxyLnyxaEDGZ7zKLbWX/1DYyM03jymR0kAMUY PYTN1LG8YKfYx2NA7fEFvoqEVsRe1DUObIJdDy7IjLNavVQoxehakXnkMLVnSD/XIEzUxVDLp 2FTn+SugPaTrELHRSxHoQbPJiUWS9Q+GUI7dG/G7VsUVfEm/o54O/xLu1pvDTRYjSB2aM8IE/ B581csi 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 21:43:44 -0000 Hi Andy, > On Apr 25, 2017, at 14:58, Andy Furniss wrote: >=20 > Dendari Marini wrote: >=20 >> 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* >=20 > I still think that once via-ethernet appears you really need the raw > parameter. Why? As far as I can tell the default mode is to adjust for the = kernel auto-added overhead (which seems to be 14 bytes for pakets headed = for an ethernet device and zero for packets headed for a ppp device). If = he adds raw, the kernel willl make its additions silently=E2=80=A6 Independent of that matter one needs to specify different overheads on = ethN and pppeN interfaces simply as the packets on the pppoN interface = have not yet been encpsulated and are 8 byte smaller than on the = respective ethN interface. I am by now thoroghly confused, so I might = have missed the subtleties in which either cake or my understanding is = wrong. > On egress ppp it likely subtracts 22 bytes on ifb that is > attached to ingress ppp 14 bytes. My understanding is again that on pppoe devices the kernel adds = zero bytes auto matically and attaching the ifb does not seem to change = that? > If you shape on real eth (eg. lan side) or ifb hooked from real eth = then > you shouldn't use raw. Ah, I thought that the non-raw mode inquires at the kernel what = overhead it intends to account for silently and simply undoes that = probably by changing the overhead passed to the kernel so that the sum = of both match what the user requested? >=20 > 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. >=20 > 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. Intersting, looking into this I learned that SACK can cause up to 40 = bytes of TCP options added to the packet... >=20 > Depending on your sync rate 17500 may be too close for ingress.