Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Wed, 5 Jun 2024 13:36:14 +0200	[thread overview]
Message-ID: <97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com> (raw)
In-Reply-To: <1078E544-F61B-4289-BCA1-BCDD9FA77481@ieee.org>

[-- Attachment #1: Type: text/plain, Size: 7988 bytes --]


Le 04/06/2024 à 22:58, Eugene Y Chang via Starlink a écrit :
> For automobiles, the sensation of speed comes from engine noise and 
> the G-force at the seat-of-your-pants.
>
> I think of it as mostly the second derivative of the motion (aka 
> acceleration).
>
> For snappiness of a network action, it is the time interval from 
> activation to completion. This perception can be enhanced by giving 
> quick feedback (response) while many things are still in motion (still 
> incomplete).
>
> We do need to agree on what makes a network snappy and how that is 
> measured.

I think a part of qualifying a communications network as 'snappy' is to 
hold a 1-to-1 long-range audio conversation that acts as much as 
possible as an in-person conversation to a person nearby. Landline 
phones still excel at that and should be the benchmark.

A 'tele-presence' over satcom linking several persons each speaking in 
high density bursts might need a 1ms RTT latency.

Alex

>
>
>
> Gene
> ----------------------------------------------
> Eugene Chang
> eugene.chang@ieee.org
>
>
>
>
>
>
>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>> Good examples Stuart, it is quite interesting that as humanity we 
>> have not come up with aggregate term what would fairly collapse the 
>> dimensions to one single metric that would describe the snappy 
>> feeling we intuitively seek for but can not quite verbalize. Vehicles 
>> have the same issues, we have top speed (F1 at 360mph feels fast 
>> compared to Starship at 16000mph), we have acceleration (Hot-rod 
>> going 0 to 60 mph in 5 seconds feels high but pales in comparison to 
>> Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor 
>> plowing field with 300hp feels great but seems small compared to 
>> 1000hp of Hot-rod) then also there is torque (tractor with 1450 Nm of 
>> torque wins a Tesla having 900Nm on wheel while at completely 
>> different torque curve).
>>
>> Capacity has the same issue as literally the truck from your example 
>> shipping magnetic tapes for "raw carry capacity" but it does not feel 
>> responsive, snappy, good to handle in the "traffic" of Internet. We 
>> have jitter, that could be compared to how a vehicle does in 
>> repeatability of track laps? We have packet loss on how the car 
>> handles on curves and does it slip off the track or on accelerations 
>> spin the wheels? Download is speed forward, upload is almost like 
>> speed at reverse gear usually far worse. Latency is like a lap track 
>> as such, depends on the track, use-case specific tests "What time did 
>> it do on Nürburgring?" or "How fast does it go from 0 to 60Mbps? Less 
>> than 200ms?". Horse power feels much like raw capacity of the HW / 
>> radio channel and techniques available beam forming, frequencies etc. 
>> what was discussed here related to Starlink and even collectively 
>> across different technologies. Speed is then instead of how much 
>> specific combination of modem and base-station combo can achieve at 
>> certain configuration? Torque feels like ability to maintain that 
>> performance, closest we get is loaded performance in context of 
>> bufferbloat?
>>
>> Watching videos on Netflix require different performance 
>> characteristics than downloading a big update to Fortnite. One has 
>> certain acceleration need to have snappy user experience but focus is 
>> more on connection stability at certain bitrate. On the other hand 
>> Fortnite update you want to be delivered at brute force speeds 
>> without ruining others user experience.
>>
>> Maybe we can not find that aggregate property or metric, but just 
>> need to be rigorous on making sure we accurately characterize each 
>> dimension and standardize them so the confusion and play with words, 
>> specially with marketing, get stabilized. Each needs to have 
>> standardized benchmarks much like 3D rendering benchmarks and PC perf 
>> tests are done? All that said, as I failed to come up with a perfect 
>> term, "varying performance ISP links" feels like the right thing to 
>> say? Now we have obfuscated to be able to throw any of the dimensions 
>> underneath. Only thing left for us to do is then to provide those 
>> dimensions like a nutrient labels. We are getting there? Nothing new 
>> under the sun also to some extend.
>>
>> Just as a funny side note on the tractor marketing:
>>
>> ”Torque gives you the feeling of responsiveness and that the machine 
>> does the right things,” Tapani Katila encapsulates his view. “The 
>> torque is directly linked to the feeling of having power available in 
>> the entire range of the power curve, resulting in more meaningful 
>> work.” from 
>> https://www.agcopower.com/power-is-important-but-torque-is-crucial/
>>
>> Seems like some other people are also trying to figure out what 
>> dimensions to showcase to customers?
>>
>> Thank you for the thought provoking examples!
>>
>> Is bufferbloat property of a vehicle or characteristic of the road 
>> design? Is it a question of ICE vs EV -or- roundabout vs crossing 
>> with traffic lights? Feels more like a roundabout, no? Is this the 
>> problem behind the objections?
>>
>> - Sauli
>>
>> On Tue, Jun 4, 2024 at 9:19 PM Stuart Cheshire via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>>     On May 7, 2024, at 18:48, Dave Taht via Starlink
>>     <starlink@lists.bufferbloat.net> wrote:
>>
>>     > This was a wonderful post, rich!
>>
>>     <https://randomneuronsfiring.com/all-the-reasons-that-bufferbloat-isnt-a-problem/>
>>
>>     I agree. Thanks for writing this Rich.
>>
>>     One minor change I will request. Any time you write words like
>>     “speed” or “fast”, pause and consider whether it would be more
>>     accurate to use some other term like “capacity”, “bandwidth”, or
>>     “throughput”. Part of what keeps us in this mess is that people
>>     equate network capacity with “speed”, as if those terms were
>>     synonyms. We can’t change how people think overnight, but at
>>     least we can avoid further reinforcing that wrong thinking.
>>
>>     If someone has 200 Mb/s Internet service and it feels slow, then
>>     they might upgrade to 400 Mb/s Internet service and expect
>>     everything to be uniformly twice as fast. We here know that
>>     doubling the network capacity may make large downloads faster,
>>     but everything else is most likely unchanged, and can be even worse.
>>
>>     People never make this mistake in other contexts. If someone
>>     commutes to work in their 20-foot RV feels that it’s too slow,
>>     then upgrading to a 40-foot RV will not get them to work faster.
>>     A 40-foot RV is *bigger* than a 20-foot RV, but it’s probably not
>>     *faster*. If you are moving a vast amount of cargo that requires
>>     multiple trips, then a larger truck will let you complete that
>>     task in fewer trips. But for most daily driving, a bigger truck
>>     will not get to your destination any quicker.
>>
>>     Some simple edits:
>>
>>     Instead of “varying speed ISP links” how about “varying capacity
>>     ISP links”?
>>
>>     Instead of “they profit if you decide your network is too slow
>>     and you upgrade to a faster device/plan” how about “they profit
>>     if you decide your network is too slow and you upgrade to a
>>     higher throughput device/plan”?
>>
>>     Stuart Cheshire
>>
>>     _______________________________________________
>>     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

[-- Attachment #2: Type: text/html, Size: 18689 bytes --]

  reply	other threads:[~2024-06-05 11: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 [this message]
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
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=97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com \
    --to=alexandre.petrescu@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