[Bloat] BBR implementations, knobs to turn?

[Neal Cardwell]

A couple questions:

- I guess this is Linux TCP BBRv1 ("bbr" module)? What's the OS
distribution and exact kernel version ("uname -r")?

- What do you mean when you say "The old server allows for more
re-transmits"?

- If BBRv1 is suffering throughput problems due to high retransmit rates,
then usually the retransmit rate is around 15% or higher. If the retransmit
rate is that high on a radio link that is being tested, then that radio
link may be having issues that should be investigated separately?

- Would you be able to take a tcpdump trace of the well-behaved and
problematic traffic and share the pcap or a plot?

https://github.com/google/bbr/blob/master/Documentation/bbr-faq.md#how-can-i-visualize-the-behavior-of-linux-tcp-bbr-connections

- Would you be able to share the output of "ss -tin" from a recently built
"ss" binary, near the end of a long-lived test flow, for the well-behaved
and problematic cases?

https://github.com/google/bbr/blob/master/Documentation/bbr-faq.md#how-can-i-monitor-linux-tcp-bbr-connections

best,
neal



On Mon, Nov 16, 2020 at 10:25 AM <erik.taraldsen at telenor.com> wrote:

> I'm in the process of replacing a throughput test server.  The old server
> is running a 1Gbit Ethernet card on a 1Gbit link and ubuntu.  The new a
> 10Gbit card on a 40Gbit link and centos.  Both have low load and Xenon
> processors.
>
>
> The purpose is for field installers to verify the bandwidth sold to the
> customers using known clients against known servers.  (4G and 5G fixed
> installations mainly).
>
>
> What I'm finding is that the new server is consistently delivering
> slightly lower throughput than the old server.  The old server allows for
> more re-transmits and has a slightly higher congestion window than the new
> server.
>
>
> Is there any way to tune bbr to allow for more re-transmits (which seems
> to be the limiting factor)?  Or other suggestions?
>
>
>
> (Frankly I think the old server is to aggressive for general purpose use.
> It seems to starve out other tcp sessions more than the new server.  So for
> delivering regular content to users the new implementation seems more
> balanced, but that is not the target here.  We want to stress test the
> radio link.)
>
>
> Regards Erik
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20201116/253c869c/attachment.html>