From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 B27D83B2A3 for ; Mon, 1 May 2017 10:46:33 -0400 (EDT) Received: by mail-wm0-x22e.google.com with SMTP id w64so89275840wma.0 for ; Mon, 01 May 2017 07:46:33 -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=IhGN50LX3UejFKZUH13tvIisWFHCQqyOKbNVyPYD+2k=; b=K23qYGm/5rMMZutpCRVJXAkOMgayEaJoYuIgxIV7gI1B53h6du9/pmAjk2KWFnjoTt p42QsC23+cE7sfuJojFpLY5va66CSlQcvrjaEzY/rEMVJCtEedbpVq2CXBRPIz/63ZXm EQcue2bZBcfKX42oBgIZe5LK5+UAHfQRjeQ4Er0DBCRKe+9Jbu1aOBi2DEafMmfJiZIh DNu2UntHr8ebyv+X/bMQ62magXjjjCphrTMU+mDLQkBNORHWMgxcuwrdSKQIKQ64SavM NiiSIjXFG6uzqLrsptgpdUrFFT3nB3hr/ubapnGEVpISnI7ucN34phvcYJNnK1PDTGyx FQGQ== 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=IhGN50LX3UejFKZUH13tvIisWFHCQqyOKbNVyPYD+2k=; b=HOwVZGlsUpw376HevfgcQg5AXO7lsh43iucxjzJXXJUR/IGeqgekym0v2CMM9dN7qU hrW/4Ztm+bRLjARctL9LxHShnnWezg20x/yDcInzI1iYfkrfmq+wktNm14ZSrkJvGMkx yrQxw0C1ld4NHnD8iWTUywZwatjxRjdHrawJzjuJG8SEP1+g0khdI82ZO9uXwK9njpsC ULubGXduWZ37m0Qz1XsOcbJtrHglKCXAgvYToXp6oBzpxaG8kgOHyThduQpEZhPzclrj pE6rqPpdYokpHp1tlfZdwHxCBKJR95MNVRKtR3T6nuW+9KVSBTMf4mjUgzkawt/R5PIo Fj8A== X-Gm-Message-State: AN3rC/5yRkmiLGSRUsHUmw0gn72U0mlELfX9aWAqgHzrIswWXJcpDocx MzIYMAUNZGqDOg== X-Received: by 10.28.91.3 with SMTP id p3mr6095123wmb.68.1493649992582; Mon, 01 May 2017 07:46:32 -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 w186sm21478110wme.26.2017.05.01.07.46.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 07:46:31 -0700 (PDT) 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> <8d2720cb-fd26-0ed8-5e59-c9a062384966@gmail.com> <963649d6-bc25-5633-3361-c0355e1c40a0@gmail.com> <395AB01F-07C0-4427-AD07-150B055EB773@gmail.com> From: Andy Furniss Message-ID: Date: Mon, 1 May 2017 15:46:30 +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: <395AB01F-07C0-4427-AD07-150B055EB773@gmail.com> 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: Mon, 01 May 2017 14:46:33 -0000 Jonathan Morton wrote: > >> On 1 May, 2017, at 16:03, Andy Furniss >> wrote: >> >> Does google/valve/every bbr user run it? > > By definition, yes. Without sch_fq, there is no pacing available for > BBR to use, and pacing is the mode it normally tries to operate in. > Without pacing, you are not in fact running BBR, but something quite > different and inferior. > > Please redo your measurements with the correct configuration at the > sender. Well I can't really test cake like this. If I need to put fq on eth of sender then I can't double queue to sim cake behind ISP. What I can do though is use ingress on target box just to sim ISP buffer and compare how it gets filled. So sender, bbr just fq on eth. netem is on ingress. Target/downloader hfsc on ingress with bfifo sim 18meg dsl oh 40. Differences to previous setup - One tcp is now very low "ISP" buffer fullness, before it was a bit higher. 5 tcps are a bit different but may fill the buffer 280ms for a while before eventually falling back to about 60ms in the case of a staggered start. Simultaneous start straight to 60ms sometimes falling to 0 then rising. Testing repeated one meg downloads looks just the same as my previous set up (ie if I just looked at "ISP" buffer by setting cake high). The latency spikes to roughly 2x the netem delay per download. Given this is the same as seen with my non pacing sim then I expect cake would have trouble stopping this (though it did make the spikes shorter time wise and a bit lower depending on backoff amount). You would miss a lot of this just pinging normally. I am testing as if on a 30Hz gameserver and plotting pings live (gnuplot).