[LibreQoS] [Starlink] It’s the Latency, FCC

Tue Apr 30 17:22:33 EDT 2024

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 at gmail.com

On Tue, Apr 30, 2024 at 11:08 PM Dave Taht via Starlink <
starlink at 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 at 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 at 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 at lists.bufferbloat.net> On Behalf Of
>> starlink-request at lists.bufferbloat.net
>> Sent: Tuesday, April 30, 2024 3:05 PM
>> To: starlink at 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 at ieee.org>
>> To: Colin_Higbie <CHigbie1 at Higbie.name>, Dave Taht via Starlink
>> <starlink at lists.bufferbloat.net>
>> Subject: Re: [Starlink] It’s the Latency, FCC
>> Message-ID: <438B1BC4-D465-497A-B6BA-700E1D411036 at 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20240430/6f1765b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 732492 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20240430/6f1765b1/attachment-0001.png>