From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8571B3B2A0; Wed, 21 Sep 2016 08:40:04 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 034E9A3; Wed, 21 Sep 2016 14:40:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1474461603; bh=SOVgQ0lipTxBSNJGINtpzRivk41RLKZ00al8rtgpr3o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sZucbKCuDq1eYr0JqwcW+XU7uavy4BJbSOVUw5vfeX2UyfJLSj0coGACZwDDPcKoK oY9T8xRdEjVOqVOdAOmBVBrNFs5KL/IMt8O0P+LcgCit+4MitlpivR3bo2l9Ail4AO A96vxqPso7sONy+eMu0p1caI8X0TnWfV8nhMDM28= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F31C1A2; Wed, 21 Sep 2016 14:40:02 +0200 (CEST) Date: Wed, 21 Sep 2016 14:40:02 +0200 (CEST) From: Mikael Abrahamsson To: Dave Taht cc: bloat , "cerowrt-devel@lists.bufferbloat.net" In-Reply-To: Message-ID: References: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Bloat] [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 12:40:04 -0000 On Wed, 21 Sep 2016, Dave Taht wrote: > * It seriously outcompetes cubic, particularly on the single queue aqms. > fq_codel is fine. I need to take apart the captures to see how well it > is behaving in this case. My general hope was that with fq in place, > anything that was delay based worked better as it was only competing > against itself. I'm looking at 4up-sqwave-fq_bfifo-256k. Is this really fq_bfifo, or just bfifo? Looks like there is no fq. If someone doesn't have the correct Flent available, I posted two screenshots here: http://imgur.com/a/cFtMd What I think I see: The flows are started in order: "BBR1, CUBIC2, BBR4, CUBIC3" (a bit confusing, but according to your description). So it looks like BBR1 fills the pipe within half a second or so, nice steady state. Then CUBIC2 starts, and slowly over a few seconds, starts to starve BBR1 of BW, it looks like steady state here would be that CUBIC2 would end up with around 65-70% of the BW, and BBR1 getting 30-35%. Then BBR4 comes along (10 seconds in), and just KILLS them both, smacks them over the head with a hammer, taking 90% of the BW, wildly oscillating in BW way above 20 megabit/s down to 10. The ping here goes up to around 150-160ms. CUBIC3 starts at 15 seconds and get basically no bw at all. Then at around 22 seconds in, I guess pretty close to 12-13 seconds after BBR4 was started, BBR4 starts to calm down, slowly letting the other streams come back to life. At around 30 seconds, they all seem to get at least a bit of the bw each and nobody is completely starved, but BBR1 seems to not get much BW at all (very dotted line). When at the end there is only CUBIC3 and BBR4 left, it looks like BBR4 has a 2/3 to 1/3 advantage. Looking at cake_flowblind_noecn, BBR1 and BBR4 just kills both CUBIC flows. Same with PIE. So it seems my intuition was wrong, at least for these scenarios. It wasn't CUBIC that would kill BBR, it's the other way around. Great to have testing tools! Thanks Flent! -- Mikael Abrahamsson email: swmike@swm.pp.se