Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>,
	Mikael Abrahamsson via Bloat <bloat@lists.bufferbloat.net>,
	starlink@lists.bufferbloat.net, dickroy@alum.mit.edu
Subject: Re: [Starlink] [Bloat]  Of interest: Comcast AQM Paper
Date: Wed, 4 Aug 2021 22:51:00 +0200	[thread overview]
Message-ID: <84E98266-8D5B-45DC-A59F-58F416AB65ED@gmx.de> (raw)
In-Reply-To: <CAJq5cE3EOQLN_NN=Nr6C=x548qAaN5_U0nkKc60PJR6iPgvLfw@mail.gmail.com>

Hi Jonathan,

> On Aug 4, 2021, at 20:28, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> I firmly believe this is due to an I/O bottleneck in the SoC between
> the network complex and the CPU complex, not due to any limitation of
> the CPU itself.  It stems from the reliance on accelerated forwarding
> hardware to achieve full line-rate throughput.  Even so, I'd much
> rather have 40Mbps with Cake than 400Mbps with a dumb FIFO.  (Heck,
> 40Mbps would be a big upgrade from what I currently have.)  I think
> some of the newer Atheros chipsets are less constrained in this
> respect.
> 
> There are two reasonably good solutions to this problem in the hands
> of the SoC vendors:
> 
> 1: Relieve that I/O bottleneck, so that the CPU can handle packets at
> full line rate.  I assume this is not hugely complicated to implement,
> and just requires a sufficient degree of will to select the right
> option from the upstream fabless IP vendor's design library.
> 
> 2: Implement good shaping, FQ, and AQM within the network complex.  At
> consumer broadband/LAN speeds, this shouldn't be too difficult (unlike
> doing the same at 100+ Gbps), but it does require a significant amount
> of hardware design and validation, and that tends to have long lead
> times.
> 
> There is a third solution in the hands of us mere mortals:
> 
> 3: Leverage the Raspberry Pi ecosystem to build a CPE device that
> meets our needs.  This could be a Compute Module 4 (which has the
> necessary I/O throughput) mounted on a custom PCB that provides
> additional Ethernet ports and some reasonable Wifi AP.  It could
> alternatively be a standard Pi 4B with some USB Ethernet and Wifi
> hardware plugged into it.  Either will do the job withhout any
> Ethernet bottlenecks, although the capabilities of USB Wifi dongles
> are usually quite limited.

Have a look at https://www.dfrobot.com/product-2242.html, which is a small carrier for the raspberry pi4 compute module that offers two gigabit ethernet ports, the one from the CM and an additional RTL81111 one connected via the PCIe lanes.

At $45 it is a bit pricy, but it sure is small and elegant.

People on the OpenWrt Forum report traffic shaping at 1Gbps rates without overloading the CPUs (this needs minimal configuration for receive side packet steering, otherwise all network IRQ and qdisc processing sticks to CPU0, in which case shaping does not reach Gbps speeds, at least not for bi-directonal traffic).

That still leaves the need for an AP and a switch (one might be able to "abuse" an AP for switch ports if in a pinch).

Regards
	Sebastian




> 
> - Jonathan Morton


  parent reply	other threads:[~2021-08-04 20:51 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01 20:20 Livingood, Jason
2021-08-01 21:39 ` Dick Roy
2021-08-04 11:49   ` Jonathan Morton
2021-08-04 12:46     ` Mikael Abrahamsson
2021-08-04 13:03       ` Sebastian Moeller
2021-08-04 13:06         ` Mikael Abrahamsson
2021-08-04 13:43           ` Sebastian Moeller
2021-08-04 18:28             ` Jonathan Morton
2021-08-04 20:44               ` David Lang
2021-08-04 20:51               ` Sebastian Moeller [this message]
2021-08-04 18:31           ` Juliusz Chroboczek
2021-08-04 18:58             ` Jonathan Morton
2021-08-04 20:08               ` Jonathan Bennett
2021-08-04 20:18                 ` Nathan Owens
2021-08-04 20:46                   ` Jonathan Bennett
2021-08-05  0:24                     ` Michael Richardson
2021-08-05 15:11                       ` Frank Carmickle
2021-08-07 23:59                         ` Michael Richardson
2021-08-07 20:31   ` Dave Taht
  -- strict thread matches above, loose matches on Subject: below --
2021-08-01 20:21 Livingood, Jason
2021-07-30 21:28 [Starlink] " Livingood, Jason
2021-07-31 17:50 ` [Starlink] [Bloat] " Simon Barber
2021-07-31 19:26   ` Aaron Wood
2021-07-31 22:55     ` Neal Cardwell
2021-08-01 13:13       ` Michael Richardson

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/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84E98266-8D5B-45DC-A59F-58F416AB65ED@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dickroy@alum.mit.edu \
    --cc=starlink@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /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