Re: [Starlink] The "reasons" that bufferbloat isn't a problem

["David Fernández" <davidfdzp@gmail.com>]

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

Hi Roland,

You remember well. That's right. In video is called glass-to-glass latency
and it can be measured with this, for example:
https://hamtv.com/latencytest.html

Regards,

David F.

On Wed, 5 Jun 2024 at 17:21, Bless, Roland (TM) <roland.bless@kit.edu>
wrote:

> Hi,
>
> On 05.06.24 at 17:16 David Fernández via Starlink wrote:
> > " 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.
>
> That is actually mouth-to-ear delay IIRC, so network delay is only a
> part of it. One has to consider play-buffering delay and codec delay
> as well. Interactive gaming usually requires smaller delays for a good
> QoE.
>
> Regards,
>   Roland
>
> > Date: Wed, 5 Jun 2024 17:10:26 +0200
> > From: Sebastian Moeller <moeller0@gmx.de <mailto:moeller0@gmx.de>>
> > To: David Lang <david@lang.hm <mailto:david@lang.hm>>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com
> > <mailto:alexandre.petrescu@gmail.com>>, Dave Taht via
> >          Starlink <starlink@lists.bufferbloat.net
> > <mailto:starlink@lists.bufferbloat.net>>
> > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> > Message-ID: <C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de
> > <mailto: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 <mailto: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: 5815 bytes --]