From: Dave Taht <dave.taht@gmail.com>
To: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: Dave Taht via Starlink <starlink@lists.bufferbloat.net>,
Eugene Y Chang <eugene.chang@ieee.org>,
Colin_Higbie <CHigbie1@higbie.name>,
libreqos <libreqos@lists.bufferbloat.net>
Subject: Re: [LibreQoS] [Starlink] It’s the Latency, FCC
Date: Tue, 30 Apr 2024 15:03:52 -0700 [thread overview]
Message-ID: <CAA93jw52c6X56UWhEw=a5ATbZokz-0K3H5VNWz=oZ3oPpvzCLw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw7iA27rm1WEvohZLVFzTqTaDt91Wf7_3D03OsOnb4dTiA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7405 bytes --]
Oh, the image from waveform was late to load. In the past months starlink
has gone from hundreds of ms of bufferbloat related latency to zero on the
upload and a mere 31ms on the download. For those that don´t know: that is
better than comcast, most fiber, all dsl, and most (non-libreqos or preseem
using) FWA, by a mile.
On Tue, Apr 30, 2024 at 3:02 PM Dave Taht <dave.taht@gmail.com> wrote:
> he also had a waveform result as best as I recall. Simpler than running
> flent.
>
> On Tue, Apr 30, 2024 at 2:23 PM Frantisek Borsik <
> frantisek.borsik@gmail.com> wrote:
>
>> Here are the tests Dave was talking about:
>>
>> [image: image.png]
>> rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/8e/3WTCbgSVMmPJBl0orVwjo8_q/rrul_be-2024-04-28T074258.845273.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/5e/mBHcvB2O-G4VByXrl_tZuLY0/tcp_ndown-2024-04-28T074032.855495.starlink-long-ipv4-1-flows.flent.gz>
>> tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz
>> <https://chat.libreqos.io/user_uploads/2/9b/rN7DZy6-0xEuPkb0N9pwoIRU/tcp_nup-2024-04-28T074143.785018.starlink-long-ipv4-1-flows.flent.gz>
>>
>> All the best,
>>
>> Frank
>>
>> Frantisek (Frank) Borsik
>>
>>
>>
>> https://www.linkedin.com/in/frantisekborsik
>>
>> Signal, Telegram, WhatsApp: +421919416714
>>
>> iMessage, mobile: +420775230885
>>
>> Skype: casioa5302ca
>>
>> frantisek.borsik@gmail.com
>>
>>
>> On Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>> Just fq codel or cake everything and you get all that.
>>>
>>> Libreqos is free software for those that do not want to update their
>>> data plane. Perhaps we should do a public demo of what it can do for every
>>> tech on the planet. Dsl benefits, fiber does also (but it is the stats that
>>> matter more on fiber because the customer wifi becomes bloated)
>>>
>>> Starlink merely fq codeled their wifi and did some aqm work (not codel I
>>> think) to get the amazing results they are getting today. I don't have the
>>> waveform test results handy but they are amazing. I feel a sea change in
>>> the wind...
>>>
>>>
>>>
>>> On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink <
>>> starlink@lists.bufferbloat.net> wrote:
>>>
>>>> Colin,
>>>> I am overwhelmed with all the reasons that prevent low(er) or
>>>> consistent latency.
>>>> I think that our best ISP offerings should deliver graceful, agile, or
>>>> nimble service. Sure, handle all the high-volume data. The high-volume
>>>> service just shouldn’t preclude graceful service. Yes, the current ISP
>>>> practices fall short. Can we help them improve their service?
>>>>
>>>> Am I asking too much?
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>> IEEE Life Senior Member
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>> Gene,
>>>>
>>>> I think the lion's share of other people (many brilliant people here)
>>>> on this thread are focused on keeping latency down when under load. I
>>>> generally just read and don't contribute on those discussions, because
>>>> that's not my area of expertise. I only posted my point on bandwidth, not
>>>> to detract from the importance of reducing latency, but to correct what I
>>>> believed to be an important error on minimum bandwidth required to be able
>>>> to perform standard Internet functions.
>>>>
>>>> To my surprise, there was pushback on the figure, so I've responded to
>>>> try to educate this group on streaming usage in the hope that the people
>>>> working on the latency problem under load (core reason for this group to
>>>> exist) can also be aware of the minimum bandwidth needs to ensure they
>>>> don't plan based on bad assumptions.
>>>>
>>>> For a single user, minimum bandwidth (independent of latency) needs to
>>>> be at least 25Mbps assuming the goal is to provide access to all standard
>>>> Internet services. Anything short of that will deny users access to the
>>>> primary streaming services, and more specifically won't be able to watch 4K
>>>> HDR video, which is the market standard for streaming services today and
>>>> likely will remain at that level for the next several years.
>>>>
>>>> I think it's fine to offer lower-cost options that don't deliver 4K HDR
>>>> video (not everyone cares about that), but at least 25Mbps should be
>>>> available to an Internet customer for any new Internet service rollout.
>>>>
>>>> Cheers,
>>>> Colin
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Starlink <starlink-bounces@lists.bufferbloat.net> On Behalf Of
>>>> starlink-request@lists.bufferbloat.net
>>>> Sent: Tuesday, April 30, 2024 3:05 PM
>>>> To: starlink@lists.bufferbloat.net
>>>> Subject: Starlink Digest, Vol 37, Issue 15
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Tue, 30 Apr 2024 09:04:43 -1000
>>>> From: Eugene Y Chang <eugene.chang@ieee.org>
>>>> To: Colin_Higbie <CHigbie1@Higbie.name>, Dave Taht via Starlink
>>>> <starlink@lists.bufferbloat.net>
>>>> Subject: Re: [Starlink] It’s the Latency, FCC
>>>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> I am always surprised how complicated these discussions become.
>>>> (Surprised mostly because I forgot the kind of issues this community care
>>>> about.) The discussion doesn’t shed light on the following scenarios.
>>>>
>>>> While watching stream content, activating controls needed to switch
>>>> content sometimes (often?) have long pauses. I attribute that to buffer
>>>> bloat and high latency.
>>>>
>>>> With a happy household user watching streaming media, a second user
>>>> could have terrible shopping experience with Amazon. The interactive
>>>> response could be (is often) horrible. (Personally, I would be doing email
>>>> and working on a shared doc. The Amazon analogy probably applies to more
>>>> people.)
>>>>
>>>> How can we deliver graceful performance to both persons in a household?
>>>> Is seeking graceful performance too complicated to improve?
>>>> (I said “graceful” to allow technical flexibility.)
>>>>
>>>> Gene
>>>> ----------------------------------------------
>>>> Eugene Chang
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>
>
> --
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
> Dave Täht CSO, LibreQos
>
--
https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
Dave Täht CSO, LibreQos
[-- Attachment #1.2: Type: text/html, Size: 13756 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 732492 bytes --]
next prev parent reply other threads:[~2024-04-30 22:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.2779.1714503924.1074.starlink@lists.bufferbloat.net>
[not found] ` <MN2PR16MB339176B8EE09E7A4D7F1EECCF11A2@MN2PR16MB3391.namprd16.prod.outlook.com>
[not found] ` <1A972680-ECA5-42CA-BE8B-6BBD46FF5E74@ieee.org>
2024-04-30 21:07 ` Dave Taht
2024-04-30 21:22 ` Frantisek Borsik
2024-04-30 22:02 ` Dave Taht
2024-04-30 22:03 ` Dave Taht [this message]
2024-05-01 3:27 ` Jim Forster
2024-05-01 7:23 ` Frantisek Borsik
2024-04-30 21:22 ` Eugene Y Chang
2024-04-30 21:35 ` Frantisek Borsik
2024-04-30 21:53 ` Eugene Y Chang
2024-05-01 0:54 ` David Lang
2024-05-01 7:27 ` Frantisek Borsik
2024-05-01 7:32 ` Brian Munyao Longwe
2024-05-01 13:25 ` Jim Forster
2024-05-01 13:48 ` Brian Munyao Longwe
2024-05-01 13:57 ` Dave Taht
2024-05-01 8:48 ` [LibreQoS] [Starlink] musings on disruption and competition [was] " Sebastian Moeller
2024-05-01 21:24 ` Eugene Y Chang
2024-05-01 19:26 ` [LibreQoS] [Starlink] " Eugene Y Chang
2024-05-14 16:05 ` Dave Taht
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/libreqos.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw52c6X56UWhEw=a5ATbZokz-0K3H5VNWz=oZ3oPpvzCLw@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=CHigbie1@higbie.name \
--cc=eugene.chang@ieee.org \
--cc=frantisek.borsik@gmail.com \
--cc=libreqos@lists.bufferbloat.net \
--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