<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21/09/16 13:40, Mikael Abrahamsson wrote:<br>
<blockquote
cite="mid:alpine.DEB.2.02.1609211413380.1477@uplift.swm.pp.se"
type="cite">On Wed, 21 Sep 2016, Dave Taht wrote:
<br>
<br>
<blockquote type="cite">* 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.
<br>
</blockquote>
<br>
I'm looking at 4up-sqwave-fq_bfifo-256k. Is this really fq_bfifo,
or just bfifo? Looks like there is no fq.
<br>
</blockquote>
<br>
the queue before the (simulated) _bottleneck_ is simple bfifo.<br>
<br>
sch_fq is used on the _endpoint_, because it's a requirement of
tcp-bbr<br>
<br>
It's disambiguated by knowing you don't add child qdiscs to sch_fq,
and no-one has written a linux qdisc called fq_bfifo. <br>
<br>
<blockquote
cite="mid:alpine.DEB.2.02.1609211413380.1477@uplift.swm.pp.se"
type="cite">
<br>
If someone doesn't have the correct Flent available, I posted two
screenshots here: <a class="moz-txt-link-freetext" href="http://imgur.com/a/cFtMd">http://imgur.com/a/cFtMd</a>
<br>
<br>
What I think I see:
<br>
<br>
The flows are started in order: "BBR1, CUBIC2, BBR4, CUBIC3" (a
bit confusing, but according to your description).
<br>
<br>
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.
<br>
<br>
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).
<br>
<br>
When at the end there is only CUBIC3 and BBR4 left, it looks like
BBR4 has a 2/3 to 1/3 advantage.
<br>
<br>
Looking at cake_flowblind_noecn, BBR1 and BBR4 just kills both
CUBIC flows. Same with PIE.
<br>
<br>
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!
<br>
<br>
</blockquote>
<br>
wow. I was wondering how BBR ever relinquished bandwidth. "With
some difficulty".<br>
<br>
Though not in the second screenshot where there's a strict AQM (cake
flowblind). Then it shares with other BBRs while never letting
CUBIC get established. (I think if you look at drops, they'd be
higher than what 4xCUBIC converges to on that link. See
<a class="moz-txt-link-freetext" href="https://groups.google.com/forum/#!msg/bbr-dev/EXgiWxHvaEU/wl3Q39svAAAJ">https://groups.google.com/forum/#!msg/bbr-dev/EXgiWxHvaEU/wl3Q39svAAAJ</a>
).<br>
</body>
</html>