From: Sebastian Moeller <moeller0@gmx.de>
To: Dave Taht <dave.taht@gmail.com>,
Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
Stuart Cheshire <cheshire@apple.com>
Cc: Starlink <starlink@lists.bufferbloat.net>,
Colin_Higbie <CHigbie1@higbie.name>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Fri, 07 Jun 2024 07:36:36 +0200 [thread overview]
Message-ID: <0D6DC1A5-4934-43A3-9F0A-A637E8FD1A76@gmx.de> (raw)
In-Reply-To: <CAA93jw5EA0BDsqYiKGho4angj_+H1x7G4z2JWfAk=Xvh+L4vWg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3047 bytes --]
This is pretty impressive... and also is a decent counter against the common argument that at BNG/backbone information rates flow queuing would be completely infeasible... or it might show that big iron silicon is just inferior to general purpose CPUs
On 7 June 2024 04:28:18 CEST, Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
>I occasionally am happy to point out the 150+ isps now running libreqos and
>cake... the several hundred running preseem and paraqum and bequant...
>
>As a rule of thumb about 10k wisp subscribers eat around 25gbit. This we
>(libreqos anyway) can do easily on a 1500 dollar whitebox (and we have
>pushed it past 60gbit in the v1.5 release entering beta shortly). This is
>usually way more capability than any given isp network segment needs...
>
>The wisps have got fq codel available native in much of their gear too, and
>of course starlink on their wifi...
>
>There are probably 60k isps left to go though. There are isps still on
>docsis 3.0. I tend to regard these issues nowadays as being demand side as
>these solutions are so widely available now...
>
>But with billions being spent to just upgrade to fiber... a dark cloud
>ahead is above 50mbit most of the bloat moves to the wifi... and despite
>eero, openwrt, Google fiber etc that have been getting it right... sigh.
>
>A bright light at the moment there is all the wifi products coming out with
>a mt79 chip.
>
>On Thu, Jun 6, 2024, 10:51 AM Stuart Cheshire <cheshire@apple.com> wrote:
>
>> On Jun 4, 2024, at 16:03, Rich Brown <richb.hanover@gmail.com> wrote:
>>
>> > Yeah... I didn't write that as carefully as I could have. I was
>> switching between "user voice" (who'll say 'speed') and "expert" voice (I
>> know the difference). Check it now:
>> https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/
>>
>> Thanks for doing that.
>>
>> How about also changing “new faster ISP plan” to “new bigger ISP plan”? I
>> know that may sound like a slightly weird phrase, but getting people’s
>> attention by surprising them a little can be beneficial. If it looks weird
>> to them and that makes them pause and think, then that’s good.
>>
>> If the hypothetical ISP imagined here were actually willing to offer a
>> plan that truly provided consistently *faster* connectivity instead of just
>> more of the same, we’d be very happy. The truth today is that most IPs
>> offer *bigger*, not *better*. They are selling quantity, not quality.
>>
>> (I am intentionally not lumping *all* ISPs into the same bucket here.
>> Some, like Comcast, are actually making big efforts to improve quality as
>> well as quantity. Comcast dramatically reduced the working latency of my
>> cable modem during the work-from-home pandemic, and they continue to work
>> on improving that even more. I want to be sure to give credit where it is
>> deserved.)
>>
>> Stuart Cheshire
>>
>>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 4023 bytes --]
next prev parent reply other threads:[~2024-06-07 5:36 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 [this message]
2024-06-07 7:51 ` Gert Doering
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=0D6DC1A5-4934-43A3-9F0A-A637E8FD1A76@gmx.de \
--to=moeller0@gmx.de \
--cc=CHigbie1@higbie.name \
--cc=cheshire@apple.com \
--cc=dave.taht@gmail.com \
--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