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) 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 > > > To: David Lang > > > Cc: Alexandre Petrescu > >, Dave Taht via > > Starlink > > > > Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem > > Message-ID: > > > > Content-Type: text/plain; charset=utf-8 > > > > Hi David, > > > > > > > On 5. Jun 2024, at 16:16, David Lang via Starlink > > > > > > 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_______________________________________________ > >