From: Gert Doering <gert@space.net>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Dave Taht <dave.taht@gmail.com>,
Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
Stuart Cheshire <cheshire@apple.com>,
Colin_Higbie <CHigbie1@higbie.name>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Fri, 7 Jun 2024 09:51:24 +0200 [thread overview]
Message-ID: <ZmK7_K49_ilDhlhs@Space.Net> (raw)
In-Reply-To: <0D6DC1A5-4934-43A3-9F0A-A637E8FD1A76@gmx.de>
Hi,
On Fri, Jun 07, 2024 at 07:36:36AM +0200, Sebastian Moeller via Starlink wrote:
> it might show that big iron silicon is just inferior to general purpose CPUs
Well, different criteria for "inferior", I'd say. A general purpose
CPU won't be able to feed something with 24x 100Gbit - and a switch
network processor won't be good for running a database...
For queueing/shaping, the network chips have become surprisingly good -
not sure about libreqos & friends, but "doing proper shaping to sub-
linerate to avoid policing drops in a carrier network further downstream"
was something switches just couldn't do, and recent gear (Jericho 2+)
does this quite well. With proper burst size configured, no bufferbloat
there either :)
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla,
Karin Schuler, Sebastian Cler
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
next prev parent reply other threads:[~2024-06-07 7:51 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s the Latency, FCC Colin_Higbie
2024-04-30 19:04 ` Eugene Y Chang
2024-05-01 0:36 ` David Lang
2024-05-01 1:30 ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01 1:52 ` Jim Forster
2024-05-01 3:59 ` Eugene Y Chang
2024-05-01 4:12 ` David Lang
2024-05-01 10:15 ` Frantisek Borsik
2024-05-01 18:51 ` Eugene Y Chang
2024-05-01 19:18 ` David Lang
2024-05-01 21:11 ` Frantisek Borsik
2024-05-01 22:10 ` Eugene Y Chang
2024-05-01 21:12 ` Eugene Y Chang
2024-05-01 21:27 ` Sebastian Moeller
2024-05-01 22:19 ` Eugene Y Chang
2024-05-06 11:25 ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11 ` Dave Collier-Brown
2024-05-07 0:43 ` Eugene Y Chang
2024-05-07 12:05 ` Dave Collier-Brown
[not found] ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47 ` Rich Brown
2024-05-07 0:38 ` Eugene Y Chang
2024-05-07 10:50 ` Rich Brown
2024-05-08 1:48 ` Dave Taht
2024-05-08 7:58 ` Frantisek Borsik
2024-05-08 8:01 ` Frantisek Borsik
2024-05-08 18:29 ` Eugene Y Chang
2024-06-04 18:19 ` Stuart Cheshire
2024-06-04 20:06 ` Sauli Kiviranta
2024-06-04 20:58 ` Eugene Y Chang
2024-06-05 11:36 ` Alexandre Petrescu
2024-06-05 13:08 ` Aidan Van Dyk
2024-06-05 13:28 ` Alexandre Petrescu
2024-06-05 13:40 ` Gert Doering
2024-06-05 13:43 ` Alexandre Petrescu
2024-06-05 14:16 ` David Lang
2024-06-05 15:10 ` Sebastian Moeller
2024-06-05 16:21 ` Alexandre Petrescu
2024-06-05 19:17 ` Eugene Y Chang
2024-06-04 23:03 ` Rich Brown
2024-06-04 23:36 ` [Starlink] Consumer Reportes (was: The "reasons" that bufferbloat isn't a problem) David Collier-Brown
2024-06-06 17:51 ` [Starlink] The "reasons" that bufferbloat isn't a problem Stuart Cheshire
2024-06-07 2:28 ` Dave Taht
2024-06-07 5:36 ` Sebastian Moeller
2024-06-07 7:51 ` Gert Doering [this message]
2024-05-02 19:17 ` [Starlink] Itʼs the Latency, FCC Michael Richardson
2024-05-02 9:09 ` [Starlink] It’s " Alexandre Petrescu
2024-05-02 9:28 ` Ulrich Speidel
2024-04-30 20:05 ` Sebastian Moeller
2024-05-02 9:21 ` Alexandre Petrescu
2024-05-07 12:13 [Starlink] The "reasons" that bufferbloat isn't a problem David Fernández
2024-05-07 12:46 ` Dave Collier-Brown
2024-05-07 19:09 ` Eugene Y Chang
2024-05-07 19:11 ` Dave Taht
2024-05-07 19:14 ` Jeremy Austin
2024-05-07 19:46 ` Dave Taht
2024-05-07 20:03 ` Eugene Y Chang
2024-05-07 20:05 ` Frantisek Borsik
2024-05-07 20:25 ` Eugene Y Chang
2024-05-08 9:31 David Fernández
2024-06-05 14:46 David Fernández
2024-06-05 14:57 ` Vint Cerf
2024-06-06 17:12 ` Michael Richardson
2024-06-06 10:18 ` Alexandre Petrescu
2024-06-06 10:37 ` Aidan Van Dyk
2024-06-06 10:33 ` Alexandre Petrescu
2024-06-05 15:16 David Fernández
2024-06-05 15:21 ` Bless, Roland (TM)
2024-06-05 15:32 ` David Fernández
2024-06-05 16:24 ` Sebastian Moeller
2024-06-06 23:10 ` Michael Richardson
2024-06-07 1:39 ` David Lang
2024-06-07 6:20 ` Sebastian Moeller
2024-06-07 17:41 ` Eugene Y Chang
2024-06-07 17:51 ` David Lang
2024-06-07 20:09 ` Eugene Y Chang
2024-06-08 1:53 ` David Lang
2024-06-05 16:23 ` Sebastian Moeller
2024-06-06 7:07 ` David Fernández
2024-06-06 7:41 ` Sebastian Moeller
2024-06-07 7:36 David Fernández
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=ZmK7_K49_ilDhlhs@Space.Net \
--to=gert@space.net \
--cc=CHigbie1@higbie.name \
--cc=cheshire@apple.com \
--cc=dave.taht@gmail.com \
--cc=moeller0@gmx.de \
--cc=starlink@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