From: Dave Taht <dave.taht@gmail.com>
To: Stuart Cheshire <cheshire@apple.com>
Cc: Rich Brown <richb.hanover@gmail.com>,
Starlink <starlink@lists.bufferbloat.net>,
Colin_Higbie <CHigbie1@higbie.name>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Thu, 6 Jun 2024 19:28:18 -0700 [thread overview]
Message-ID: <CAA93jw5EA0BDsqYiKGho4angj_+H1x7G4z2JWfAk=Xvh+L4vWg@mail.gmail.com> (raw)
In-Reply-To: <A3CE08FF-6DEA-4071-B568-8BCF7369E3D0@apple.com>
[-- Attachment #1: Type: text/plain, Size: 2570 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 3295 bytes --]
next prev parent reply other threads:[~2024-06-07 2:28 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 [this message]
2024-06-07 5:36 ` Sebastian Moeller
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='CAA93jw5EA0BDsqYiKGho4angj_+H1x7G4z2JWfAk=Xvh+L4vWg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=CHigbie1@higbie.name \
--cc=cheshire@apple.com \
--cc=richb.hanover@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