Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Sebastian Moeller <moeller0@gmx.de>,
	 Hesham ElBakoury via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] It’s the Latency, FCC
Date: Tue, 30 Apr 2024 08:01:01 -0700 (PDT)	[thread overview]
Message-ID: <o8qnq4so-8914-0634-6884-or3r783910pp@ynat.uz> (raw)
In-Reply-To: <727b07d9-9dc3-43b7-8e17-50b6b7a4444a@gmail.com>

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

On Tue, 30 Apr 2024, Alexandre Petrescu via Starlink wrote:

> I agree with you: two distinct parameters, bandwidth and latency.  But 
> they evolve simultenously, relatively bound by a constant relationship.  
> For any particular link  technology (satcom is one) the bandwidth and 
> latency are in a constant relationship.  One grows, the other 
> diminishes.  There are exceptions too, in some details.

No, As a general rule you do not have to accept poor latency to get good speed.

at least not until the link is very close to full utilization. But below some 
figure (depending on how you are managing latency, it may be 80% utilization, 
90% utilization, or even higher), there is no bandwidth gain from lowering 
latency.

Even for media that batches traffic (wifi), the bandwidth tradeoff between 'send 
everything you have now, let anything that misses this window go out in the next 
transmission' vs 'delay sending anything just in case there is more that will 
arrive and can be sent in the same transmission slow instead of it having to 
wait' only affects the bandwidth used in the first transmission op, after that 
the bandwidth usage will be the same, but you have better latency. Now when you 
try to add fairness for something like this you may end up costing latency 
and/or bandwidth, but that's a different discussion than there being a 
latency/bandwith constant relationship like you claim.

So I very much disagree that you have to trade off latency for bandwidth.

There may be some special data link technologies were there is a 
bandwidth/latency tradeoff, but I am not aware of them (please educate me if 
there are ones that I am not aware of)

David Lang

  parent reply	other threads:[~2024-04-30 15:01 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.2769.1714483871.1074.starlink@lists.bufferbloat.net>
2024-04-30 14:00 ` Colin_Higbie
2024-04-30 14:25   ` Alexandre Petrescu
2024-04-30 14:32     ` Sebastian Moeller
2024-04-30 14:40       ` Alexandre Petrescu
2024-04-30 14:45         ` Sebastian Moeller
2024-04-30 14:56           ` Alexandre Petrescu
2024-04-30 15:04             ` David Lang
2024-04-30 15:01         ` David Lang [this message]
2024-05-06 15:42 David Fernández
  -- strict thread matches above, loose matches on Subject: below --
2024-05-06 13:21 David Fernández
2024-05-03  9:09 [Starlink] It's " David Fernández
     [not found] <mailman.2877.1714641707.1074.starlink@lists.bufferbloat.net>
2024-05-02 14:47 ` [Starlink] It’s " Colin_Higbie
2024-05-02 19:50   ` Frantisek Borsik
2024-05-06 11:19     ` Alexandre Petrescu
2024-05-06 13:43       ` Nathan Owens
2024-05-06 15:22         ` Colin_Higbie
2024-05-14 19:23       ` Colin_Higbie
2024-05-15  6:52         ` Sebastian Moeller
2024-05-15 14:55           ` Colin_Higbie
2024-05-03  1:48   ` Ulrich Speidel
2024-05-03  7:22     ` Jeremy Austin
2024-05-03  9:02     ` Alexandre Petrescu
2024-05-03  8:29   ` Alexandre Petrescu
2024-05-03  8:34   ` Alexandre Petrescu
2024-05-01 16:35 [Starlink] It's " David Fernández
2024-05-01  8:41 David Fernández
     [not found] <mailman.2785.1714507537.1074.starlink@lists.bufferbloat.net>
2024-04-30 20:48 ` [Starlink] It’s " Colin  Higbie
2024-04-30 20:49   ` Colin_Higbie
2024-05-01  0:51   ` David Lang
     [not found] <mailman.2779.1714503924.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:31 ` Colin_Higbie
2024-04-30 19:51   ` Eugene Y Chang
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
2024-04-30 22:05         ` [Starlink] Fwd: " Rich Brown
2024-04-30 22:10           ` Dave Taht
2024-04-30 22:42             ` [Starlink] " Rich Brown
2024-04-30 23:06               ` Dave Taht
2024-04-30 22:31           ` Eugene Y Chang
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 19:26               ` Eugene Y Chang
2024-05-14 16:05                 ` Dave Taht
     [not found] <mailman.2775.1714488970.1074.starlink@lists.bufferbloat.net>
2024-04-30 19:12 ` Colin_Higbie
2024-04-30 19:31   ` Eugene Y Chang
2024-05-01  0:33     ` David Lang
2024-05-01  0:31   ` David Lang
2024-05-01  0:40     ` [Starlink] It?s " David Lang
     [not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s " Colin_Higbie
2024-04-30 19:04   ` Eugene Y Chang
2024-05-01  0:36     ` David Lang
2024-05-02  9:09     ` Alexandre Petrescu
2024-05-02  9:28       ` Ulrich Speidel
2024-04-30 20:05   ` Sebastian Moeller
2024-05-02  9:21     ` Alexandre Petrescu
2024-04-30  9:54 David Fernández
     [not found] <mailman.2495.1710610618.1074.starlink@lists.bufferbloat.net>
2024-03-16 19:10 ` Colin_Higbie
2024-03-16 19:32   ` Sebastian Moeller
2024-03-17 17:00   ` Alexandre Petrescu
2024-03-17 19:26     ` Frantisek Borsik
     [not found] <mailman.11.1710518402.17089.starlink@lists.bufferbloat.net>
2024-03-15 18:32 ` Colin  Higbie
2024-03-15 18:41   ` Colin_Higbie
2024-03-15 19:53     ` Spencer Sevilla
2024-03-15 20:31       ` Colin_Higbie
2024-03-16 17:18         ` Alexandre Petrescu
2024-03-16 17:21           ` Alexandre Petrescu
2024-03-16 17:36           ` Sebastian Moeller
2024-03-16 22:51             ` David Lang
2024-03-15 23:07       ` David Lang
2024-03-16 18:45         ` [Starlink] Itʼs " Colin_Higbie
2024-03-16 23:05           ` David Lang
2024-03-17 15:47             ` [Starlink] It’s " Colin_Higbie
2024-03-16 18:51         ` [Starlink] It?s " Gert Doering
2024-03-16 23:08           ` David Lang
2024-04-30  0:39   ` [Starlink] It’s " David Lang
2024-03-15  3:53 Larry Press
2024-03-15  5:33 ` Dave Taht
2024-03-15 21:14   ` Michael Richardson

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=o8qnq4so-8914-0634-6884-or3r783910pp@ynat.uz \
    --to=david@lang.hm \
    --cc=alexandre.petrescu@gmail.com \
    --cc=moeller0@gmx.de \
    --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