From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 6D95E3B2A3 for ; Tue, 25 Apr 2017 08:58:15 -0400 (EDT) Received: by mail-wm0-x241.google.com with SMTP id d79so24850268wmi.2 for ; Tue, 25 Apr 2017 05:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=GvgKMRZuh21hYnenCde8yE55w1dGJ5Td5SVWg8rncqI=; b=U7p2HOo7ZwmXjL4YDTtXw2VQZUcm8OO26PIYSZvheXseCZZyvDuxrxg3XOLhD6LqRn KfPgMR0729zXNEbRn+fy3WmzCwpfgW08uZwHH5Wwm9IwO+EbJqyszezFGNNPm1sElNRM yyVqQmOZDLYpD5JRiO4Ygq0csj0vCbz/IzRgaJYyUAaDXDuZXy8p3/DPoTBeka59n2/6 sm4ieElVx68+3DfAz/8Aznu0s107yHUGKpjpFbj0he0xUfX6iVrC6kR2oUZZ9zv2aCNy dQ2UnyVzmfrX43HO3zoyeIUQEM1oD2ZHsbGBLYNBQJpxAEStSj0QvUAXg/gr89LDpRCD tJug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GvgKMRZuh21hYnenCde8yE55w1dGJ5Td5SVWg8rncqI=; b=WQM7SoKsIvFm2bjyD1Az4Q9kGNaK6Xmnr5zR/NvMVX8aE5xxM4Y/FKN6hUS+FH0WNv ZM3IjjY5JXC13edZmxxbSJvjOsW2norD0gJKAOxVbRVgeeIVUZ2mQ4s0+G5GYN40vEsM LXq6H2DPZpJfiyk3sqbzJrJd+kiXtu0x4GwyH7KBh/fOGuFUqLA/sBZE7DQo8+yJUN4O DxQUYmPTs6s27pwLkXlBcV6qpfIZCcOQtuYDJbe3f0EgWsQD0+jGAJC4kG8AskQH2clA etlHWWgOp2DKhsZLxfNg4UdKLiwrWt487S13HowVY+KF+y5f6ve/b3RQDCeAR43iHnY9 uJyw== X-Gm-Message-State: AN3rC/59gzf700KY970Q0thMN9hSNskq+8fM5pQuTRRdaavzVrONcUjO fZSGGM0ObECkhQ== X-Received: by 10.28.134.142 with SMTP id i136mr1805792wmd.14.1493125094458; Tue, 25 Apr 2017 05:58:14 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id b93sm5979785wrd.29.2017.04.25.05.58.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 05:58:13 -0700 (PDT) To: Dendari Marini Cc: Sebastian Moeller , cake@lists.bufferbloat.net 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> From: Andy Furniss Message-ID: <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> Date: Tue, 25 Apr 2017 13:58:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 12:58:15 -0000 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.