From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 A4A033B29E for ; Sat, 29 Apr 2017 20:05:21 -0400 (EDT) Received: by mail-wm0-x22b.google.com with SMTP id w64so67156929wma.0 for ; Sat, 29 Apr 2017 17:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Y8ezf/+yekiPcWM3a8qOPeC8h7OLTCobKZmazqkkedo=; b=WXbkwLkY4/GUIPJljWeEVNH1MTADUoJPAjwg/qjevcTLvY0U8YoBtW/qZrihpyKfNU Q8DiLfp0jqd4JTF3lMzjCQPKBfOb+23J5TvJABIDBPbBENS8FuqiK5ptI4JAnalEAKBW a/17zg1opN07foTJAuRtWQS3ueLG2KnMLNApjhVw/VfEOxJTOMjfwNZTAYIJXXv0np5m 3iUCpi0bs0smFjSjhRx+MCpQPmjG95M944Q5ZWGFWJv9UUZrmtyyXVySSFvKlwZSNfC0 1kKfVvab8rtM9cZsDtuVMvpChcyawG2+/c1TGH0ayslTydATcLHGozNN0NpoyKkc6dHu aVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Y8ezf/+yekiPcWM3a8qOPeC8h7OLTCobKZmazqkkedo=; b=MzVzck3Y+HXw393o8FBt08JsQhiY9QI9txQroGevjnuTfFa6SXudRG+niKO698bdLc Z5TmazT9cvFyguyKpUb3yuiyQ2rYamIKBFPs4V8R/CGy5Y6bleZ0WgreKCkRXWOf9BiJ Y+iy506D0NQ6teyq6IEdwmuvQ0OZpt0ghPIROmNPvpR9Q+xUjPI/T9cVtW/c058WGUPd HkdKgA5+qBbP0XGgxH6r619pmvySDdQoXjfXgnA44i0xxTCQZ4hXcl6ga878l1D+WyTH VsAeeFjheB23OT2qv6DiApMNWuSmyWkpzon2vRPnmlV8Rfpxv7EaxsLE0IqJ3Fk1z1D7 c1Hw== X-Gm-Message-State: AN3rC/7An3scc6Z/588C1n6HJSZuE1m3Tg7hehtVSEIcwrKoWBMK1O53 CBEhKX1bn+lOvw== X-Received: by 10.28.234.144 with SMTP id g16mr2740484wmi.61.1493510720497; Sat, 29 Apr 2017 17:05:20 -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 188sm4504505wmf.29.2017.04.29.17.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 17:05:18 -0700 (PDT) From: Andy Furniss To: Jonathan Morton Cc: Dendari Marini , Benjamin Cronce , cake@lists.bufferbloat.net References: <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> <3fbfd0ee-7b41-0f83-8b44-ce7eed6a0562@gmail.com> <09DB0D8E-F63C-4126-8608-9EACDE99D2F1@gmail.com> <64b0e940-84ae-e75c-0ddb-10e60452c59a@gmail.com> <3FA974FA-E306-42FC-9CBD-0F5B5F8CABED@gmail.com> Message-ID: <93a030eb-f96a-5751-89ef-99b1bbbb8fbd@gmail.com> Date: Sun, 30 Apr 2017 01:05:18 +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: 8bit 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: Sun, 30 Apr 2017 00:05:21 -0000 Andy Furniss wrote: > Jonathan Morton wrote: >> >>> On 29 Apr, 2017, at 18:11, Andy Furniss >>> wrote: >>> >>> With the ingress param shaping at 1mbit 5 tcps (cubic or bbr) >>> really destroys latency. >>> >>> With the caveat that my test may be flawed, I am currently >>> suspecting that cake cobalt head + ingress param and a low rate >>> is buggy. >> >> That’s odd, since I’m currently dogfooding it at 512Kbit, and it >> works fine like that. Not to the point of wanting to play online >> games while torrenting and downloading Steam updates, but that >> sort of limitation comes with the territory. >> >> With a game updater that uses *80* web-seeds simultaneously (a >> libtorrent quirk which should get patched in the next version), I >> can still reliably use my Web browser and e-mail on a second >> machine; these are things that start to fail intermittently over >> about 2 seconds RTT, and I’ve measured this ISP at 45 seconds >> without modification. >> >> The key thing to remember is that in ingress mode, you *must* >> reduce the shaped rate to some (large) fraction of the bottleneck >> link, otherwise it won’t control the queue at all. For example, >> I’m reasonably sure my current link is dumb-shaped to 576Kbit at >> the ISP. The smaller the fraction, the better the control of >> latency Cake can achieve. >> >> This is in contrast to egress mode, where you want to match the >> link capacity as closely as possible to get maximum performance; >> latency control remains ideal as long as you never actually >> *exceed* the true link capacity. > > It was a rather artificial test with cake set at 1mbit behind hfsc > at 18mbit - just trying to recreate one of Dendari's tests. With the > ingress parameter latency was hurt quite badly compared to without, > which was unexpected. There were a lot of drops - but it seemed like > they were hurting the ping flow. Putting ping into voice didn't > help. Also seen on a very simple test case with cake on eth. In this case brr is worse than cubic, but both are "bad". I am guessing that the ingress param just shouldn't be used when it's not (as you said) a large fraction of the bottleneck. I suspect that with low bandwidth + many drops + pretending the drops were sent, that the whole queue goes over rate, rather than just the individual flows.