Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: "David Fernández" <davidfdzp@gmail.com>
To: starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Wed, 5 Jun 2024 17:16:44 +0200	[thread overview]
Message-ID: <CAC=tZ0r1jrAo88fw4OpAXHZNJ_vCnYfxVyS5rywyiS4oMs1sng@mail.gmail.com> (raw)

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

Hi Sebastian,

" Our local regulator thinks that 150 ms access network OWD (so 300msRTT)
is acceptable"

Your local regulator is following ITU-T advice in Recommendation G.114,
where it is said that up to 150 ms one-way delay is acceptable for
telephony.

Regards,

David F.

Date: Wed, 5 Jun 2024 17:10:26 +0200
From: Sebastian Moeller <moeller0@gmx.de>
To: David Lang <david@lang.hm>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Dave Taht via
        Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de>
Content-Type: text/plain;       charset=utf-8

Hi David,


> On 5. Jun 2024, at 16:16, David Lang via Starlink <
starlink@lists.bufferbloat.net> wrote:
>
> Alexandre Petrescu wrote:
>
>> Le 05/06/2024 à 15:40, Gert Doering a écrit :
>>> Hi,
>>>
>>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via
Starlink
>> wrote:
>>>> well, ok.  One day the satcom latency will be so low that we will not
have
>>>> enough requirements for its use :-)
>>> Your disbelief in physics keeps amazing me :-)
>>
>> sorry :-)  Rather than simply 'satcom' I should have said
satcom-haps-planes-drones.  I dont have a name for that.
>
> you would be better off with plans that don't require beating the speed
of light. Yes, quantum entanglement may be a path to beat the speed of
light, but you still need the electronics to handle it, and have the speed
of sound at temperatures and pressures that humans can live at as a
restriction.
>
> by comparison to your 1ms latency goals, extensive AT&T phone testing
decades ago showed that 100ms was the threshold where people could start to
detect a delay.

Would you have any pointer for that study/those studies? Our local
regulator thinks that 150 ms access network OWD (so 300msRTT) is acceptable
and I am trying to find studies that can shed a light on what acceptable
delay is for different kind of interactive tasks. (Spoiler alert, I am not
convinced that 300ms RTT is a great idea, I forced my self to remote
desktop with artificial 300ms delay and it was not fun, but not totaly
unusable either, but then human can adapt and steer high inertia vehicles
like loaded container ships...)

Sorry for the tangent...

Regards
        Sebastian

P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of
sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343
m/millisecond that is even at a distance of 1 meter delay will be at a 3
ms... and when talking to folks 10m away it is not the delay that is
annoying, but the fact that you have to raise your voice considerably...

>
> David Lang_______________________________________________

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

             reply	other threads:[~2024-06-05 15:17 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05 15:16 David Fernández [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2024-06-07  7:36 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-05-08  9:31 David Fernández
2024-05-07 12:13 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
     [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 18:51               ` Eugene Y Chang
2024-05-01 19:18                 ` David Lang
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-06 17:51                                 ` Stuart Cheshire
2024-06-07  2:28                                   ` Dave Taht
2024-06-07  5:36                                     ` Sebastian Moeller
2024-06-07  7:51                                       ` Gert Doering

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='CAC=tZ0r1jrAo88fw4OpAXHZNJ_vCnYfxVyS5rywyiS4oMs1sng@mail.gmail.com' \
    --to=davidfdzp@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