From: Dave Taht <dave.taht@gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: bloat <bloat@lists.bufferbloat.net>, Rpm <rpm@lists.bufferbloat.net>
Subject: Re: [Rpm] [Bloat] *under*bloated networks
Date: Sun, 28 Nov 2021 10:24:12 -0800 [thread overview]
Message-ID: <CAA93jw6=pXerUdehMWQYjCj+LDVzArhRcGwCbu-Sgw=TB3vOiA@mail.gmail.com> (raw)
In-Reply-To: <CADVnQynenp-VJ=ECm5QBvSQ1Y-uyj95=XftDNqXuWdHCDd02yQ@mail.gmail.com>
On Sun, Nov 28, 2021 at 7:42 AM Neal Cardwell <ncardwell@google.com> wrote:
>
>
>
> On Mon, Nov 22, 2021 at 10:35 PM Dave Taht <dave.taht@gmail.com> wrote:
>>
>> In the last two weeks I have found two dramatically underbuffered Gbit
>> fiber networks.
>>
>> This one appears to have about a 400 full size packet uplink buffer (5ms)[1]
>>
>> https://imgur.com/a/Bm9hdNf
>>
>> It was pretty remarkable to see how well multiple tcp flows still
>> achieved close to the full rate with such a small fixed size queue,
>> eventually.
And baseline rtts not increasing more than 5ms before seeing a drop with cubic.
https://imgur.com/a/S5v2EF3
>>
>> A single bbr flow can't crack 150mbits: https://imgur.com/a/DpydL5K.
>
>
> Thanks, Dave. The single-flow BBR upload case is interesting.
>
> I took a look at the packet traces in the later thread:
> https://www.reddit.com/r/eero/comments/qxbkcl/66_is_out/hltlep0/
>
> For the single-flow BBR case it seems that....
>
> (1) the BBR(v1) flow is running into a 300 Mbps bottleneck rate (visible in the slope of the green ACK line in the zoomed-in trace, attached).
This particular bottleneck is capable of a gbit, according to the 8
flow tests. A single cubic flow peaks at 300Mbit,
in earlier tests.
> (2) the BBR(v1) flow is achieving an average rate a bit above 150 Mbps because it repeatedly runs into receive window limits (the yellow line in the zoomed-out trace, attached). The frequent receive window limits mean that the flow spends a lot of time unable to send anything, thus leading to lower average throughput.
In all honesty, I haven't looked at BBR, + long rtts, and rates >
100Mbit often enough. (I actually have never had more than a 35Mbit
uplink to the internet in my whole life.) What I see here is a big
sack block, and that pause, and yes, the window getting smaller... And
universally, this fellah's link kicking flows out of slow start at
around 100Mbit... but what does it mean?
this server is running 5.11.0-40-generic #44-Ubuntu SMP, if there is
something I can tune.
Most speedtest sites use 8+ flows on the upload portion of the test...
>
> cheers,
> neal
>
--
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
Dave Täht CEO, TekLibre, LLC
prev parent reply other threads:[~2021-11-28 18:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 3:35 [Rpm] " Dave Taht
2021-11-28 15:42 ` [Rpm] [Bloat] " Neal Cardwell
2021-11-28 18:24 ` Dave Taht [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw6=pXerUdehMWQYjCj+LDVzArhRcGwCbu-Sgw=TB3vOiA@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=ncardwell@google.com \
--cc=rpm@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox