<div dir="ltr"><div>Hi Roland,</div><div><br></div><div>You remember well. That's right. In video is called glass-to-glass latency and it can be measured with this, for example:</div><div><a href="https://hamtv.com/latencytest.html">https://hamtv.com/latencytest.html</a></div><div><br></div><div>Regards,</div><div><br></div><div>David F.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 Jun 2024 at 17:21, Bless, Roland (TM) <<a href="mailto:roland.bless@kit.edu">roland.bless@kit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 05.06.24 at 17:16 David Fernández via Starlink wrote:<br>
> " Our local regulator thinks that 150 ms access network OWD (so <br>
> 300msRTT) is acceptable"<br>
> <br>
> Your local regulator is following ITU-T advice in Recommendation G.114, <br>
> where it is said that up to 150 ms one-way delay is acceptable for <br>
> telephony.<br>
<br>
That is actually mouth-to-ear delay IIRC, so network delay is only a <br>
part of it. One has to consider play-buffering delay and codec delay<br>
as well. Interactive gaming usually requires smaller delays for a good<br>
QoE.<br>
<br>
Regards,<br>
Roland<br>
<br>
> Date: Wed, 5 Jun 2024 17:10:26 +0200<br>
> From: Sebastian Moeller <<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a> <mailto:<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>>><br>
> To: David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a> <mailto:<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>>><br>
> Cc: Alexandre Petrescu <<a href="mailto:alexandre.petrescu@gmail.com" target="_blank">alexandre.petrescu@gmail.com</a> <br>
> <mailto:<a href="mailto:alexandre.petrescu@gmail.com" target="_blank">alexandre.petrescu@gmail.com</a>>>, Dave Taht via<br>
> Starlink <<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a> <br>
> <mailto:<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>>><br>
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem<br>
> Message-ID: <<a href="mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de" target="_blank">C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de</a> <br>
> <mailto:<a href="mailto:C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de" target="_blank">C1BCE67C-E4D3-4626-B9FB-1AD35C8D93CD@gmx.de</a>>><br>
> Content-Type: text/plain; charset=utf-8<br>
> <br>
> Hi David,<br>
> <br>
> <br>
> > On 5. Jun 2024, at 16:16, David Lang via Starlink <br>
> <<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a> <mailto:<a href="mailto:starlink@lists.bufferbloat.net" target="_blank">starlink@lists.bufferbloat.net</a>>> <br>
> wrote:<br>
> ><br>
> > Alexandre Petrescu wrote:<br>
> ><br>
> >> Le 05/06/2024 à 15:40, Gert Doering a écrit :<br>
> >>> Hi,<br>
> >>><br>
> >>> On Wed, Jun 05, 2024 at 03:28:45PM +0200, Alexandre Petrescu via <br>
> Starlink<br>
> >> wrote:<br>
> >>>> well, ok. One day the satcom latency will be so low that we will <br>
> not have<br>
> >>>> enough requirements for its use :-)<br>
> >>> Your disbelief in physics keeps amazing me :-)<br>
> >><br>
> >> sorry :-) Rather than simply 'satcom' I should have said <br>
> satcom-haps-planes-drones. I dont have a name for that.<br>
> ><br>
> > you would be better off with plans that don't require beating the <br>
> speed of light. Yes, quantum entanglement may be a path to beat the <br>
> speed of light, but you still need the electronics to handle it, and <br>
> have the speed of sound at temperatures and pressures that humans can <br>
> live at as a restriction.<br>
> ><br>
> > by comparison to your 1ms latency goals, extensive AT&T phone testing <br>
> decades ago showed that 100ms was the threshold where people could start <br>
> to detect a delay.<br>
> <br>
> Would you have any pointer for that study/those studies? Our local <br>
> regulator thinks that 150 ms access network OWD (so 300msRTT) is <br>
> acceptable and I am trying to find studies that can shed a light on what <br>
> acceptable delay is for different kind of interactive tasks. (Spoiler <br>
> alert, I am not convinced that 300ms RTT is a great idea, I forced my <br>
> self to remote desktop with artificial 300ms delay and it was not fun, <br>
> but not totaly unusable either, but then human can adapt and steer high <br>
> inertia vehicles like loaded container ships...)<br>
> <br>
> Sorry for the tangent...<br>
> <br>
> Regards<br>
> Sebastian<br>
> <br>
> P.S.: Dave occasionally reminds us how 'slow' in comparison the speed of <br>
> sound is ~343 m/second (depending on conditions) or 343/1000 = 0.343 <br>
> m/millisecond that is even at a distance of 1 meter delay will be at a 3 <br>
> ms... and when talking to folks 10m away it is not the delay that is <br>
> annoying, but the fact that you have to raise your voice considerably...<br>
> <br>
> ><br>
> > David Lang_______________________________________________<br>
<br>
</blockquote></div>