From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EC5153B2A4 for ; Thu, 6 Jun 2024 03:22:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1717658553; x=1718263353; i=moeller0@gmx.de; bh=GADh7qLPLz8zWDXZKhWh7yWzcH7xAavZiFKSLU4Q7OU=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=SE0d3lcqYRMDJBO4O/THiFjzJ4nDYNDP88buCydQuU9sP028YymjRAjvL2Xy5FwX yTAtcZ3o+V2dfhaNgNSopUjjS673dlcHL6cG9GSf1X8XD0KWgphUe9S4WUJImjQie 5UJVrtgaFHXDjKwnafmLgaV201PEVASmntxRD9k0A6IIMkugHMUvZOMi6uA34Dic8 qrDFTEyrAZc+qLIhVbAlMxC+PP91IGVmnAsjAfXjvxT0ufY4icbu8CCzDMJB9X44E O0ucpGO700DJ0WRzQTJwQ91kRNyLzD/+f6CgGOhKUzd25VOlhq16EyyJ6y2pEN7kl ZDfM6rjbnhmPTdveFQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M6DWs-1sLkDh2itc-005a4B; Thu, 06 Jun 2024 09:22:33 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 6 Jun 2024 09:22:23 +0200 Cc: "starlink@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: <64FC2A3B-D512-4270-9285-C5AD69BBE40E@gmx.de> References: To: Colin_Higbie X-Mailer: Apple Mail (2.3774.600.62) X-Provags-ID: V03:K1:PQDu2bX60fB1IjlxDWqE368xSIcxgrf8V50NFHxmWkwG0Y0srE0 VPBNHCxvjonSSQDGgdtFycNG2rCQY79GnFe3lZUpR4na9xx0AwWM4c87xr8qJPUlV5qqnUx D1F+99orsWbO3DgxqWZ2mszz7R8+JaLTVyLd8tkSi+wlQpUWQ3itEmaOXfjMXo36iWlnpg3 jAgNN3muDavPS7Jt3noXQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:6pfmUj17EEg=;v56xIGoHOhgu33biytnD1wBDoZ6 YCqlKxBzx6/PCj9iTD5wgt0SuK7z071Yq3rF1NwaB+IdwfCpZQFyYiYqWAN/2cDfAlHmV6QPl PcSEeONKDkWzdq0/0o0ji4rwi+zHTa8kg5jj3Hn8l6eXQhyfgcTiFMqYHwdOc1CEPGHUpinDc JDszsoSBWi7UsG5z19L+si/QyB5HDQqVynUDCNLqQUsotRDFdyFpdR+shdBN46K/EUX6aLmyk 77G3IMCRrGTAJNUbO1Mj3HZJUl/iAQVig6wlmYk+KPWudChKWh7ZxsRlRrk8w9qOg3PLrk0Up 15m6N86oTDTOkT/QPPQquNApBXhFQ+A8ZkC2oNt3IYs8O+5vhK/eGia15w3GSdG2uEp1kYN12 KIxcVCYn3o/DziQyA8XDh18s7G0y+XUaE/Qjl6A9OPB1ttElNuJFjkVp0oayTk1IHNv588I2N 1B4+Ng0Uibfv05pHjVviaYR/+DgIEmmxgMeX+hhBmvFap/7di01wdTYbJnTJbYFesXexcsYWm 0J2sFc+4YXnjUlCsJEvMz3H1Fcy4G+MHsJWUcjEr1TurJFD+oaF1XQvWgQ3sSLZ/8srICLbSw UacJP33pE9TmoyD59puUI71Jsj3X6k+lArXs01UCZzPFKN468PHG1rt6YXSAn6ab9GRNr5ZWx 6w2sq2OZjJ0OyMirw7h4tNiMQO1isNUDtPnqB4IfDfHt3h6tGCraw9WL8B/eg2wmJ9XyYLKsn C6O29cCbybWYHTss3aghj7Q/mljQgPAnJm/oFO+9kRfKlT2rp3049ed6Cyn/9NURUSZ/448me yCnmZ4Ow8ggSzRADvZO3Eytz4AtFDJZ6ZjINg+fp+6zF8= Subject: Re: [Starlink] 300ms Telecommunication Latency and FTL Communication X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2024 07:22:38 -0000 Hi Colin, > On 5. Jun 2024, at 19:58, Colin_Higbie wrote: >=20 > Sebastian, >=20 > At 300ms RTT, that would mean the starting point for any = communications are already at the threshold of unacceptability. [SM] Not according to the ITU (114) mouth-ear delay in ms (so OWDs) 0-200ms: users very satisfied 200-275ms: users satisfied 275-375ms: some users dissatisfied 375-600: many users dissatisfied 600-...: nearly all users dissatisfied So even 150ms OWD still falls within the very satisfied range if the = remaining delay is not to large... And even if er string two of these = users together, we end up with worst case >300ms delay, but that sill = only gets us into the "some users dissatisfied" which the regulator = might find an acceptable trade-off in the context of guaranteed internet = access parameters (where the idea is the 150ms OWD or 300ms RTT is not = the target, but the threshold for being acceptable). My gut feeling is these ranges are not actually measured in a way they = are now interpreted (e.g. when testing transatlantic call delays users = likely already had an expectancy of longer delay and simply judges these = calls against a different yard stick). BUT unless I can demonstrate that = the original studies resulting in these numbers are terminally flawed = there is little chance that I can convince our regulator to take my word = vor voice delays over the word of the ITU... so I need different, = preferably newer data and focus on probably remote desktop usage as a = relative novel use case without much encrusted ideas about acceptable = latency... > I would think the strongest argument is that's at best a passable = latency in absolutely perfect conditions, which never exist. "Pleasant" = communication latency is sub-100ms, adding additional travel time to the = actual servers involved and processing at each end, the ISP needs to do = significantly better than that target to provide some margin for those = other sources of latency, many controlled by fundamental physics sending = the signal over distance. [SM] Personally I agree, yet I am not sure picking a fight over the VoIP = numbers is going to be productive, as I have considerably less clout = with the regulator than the ITU... Regards Sebastian >=20 > By the way, on the original subject of quantum entanglement and FTL = communication: the current theory and experimental data on quantum = entanglement do not permit FTL communications. Yes, particles can = exchange state information with their entangled particle FTL (tested and = verified, possibly instantaneous or within a Planck-unit of time ~10^-44 = seconds), but no information can be conveyed this way. Information = transfer is still limited to the speed of light, as far as we know. This = is because if particle A and B are entangled with respect to spin (i.e., = if A has spin up, then B must have spin down and vice versa), and = someone with particle A changes its spin, the only thing a person can do = at particle B is query it once. The person at particle B will know the = spin of A and B, but has no way of knowing if that's the spin before or = after the person at A changed it. And because they can't check it = multiple times (first check collapses the wave function), they have no = way of knowing if it changed or when. The only way to check would be to = use conventional communications, limited to the speed of light, which = defeats any benefit to the FTL state change.=20 >=20 > While it's always possible we'll overcome what appear to be current = limitations of physics, it's nothing that's likely in our near future. = This is fairly fundamental quantum mechanical property and relates to = the fact that you change the state and collapse the wave function when = you observe the particle. Even attempts to use large numbers of = particles in the hope of catching a statistical change across many has = not been able to overcome this fundamental property of quantum = entanglement.=20 >=20 > Best I've heard on this is the somewhat-famous-in-Physics-circles = hypothesis that ER =3D EPR, referring to the paper by Einstein and Rosen = on wormholes (the Einstein-Rosen bridge) =3D the paper by Einstein, = Rosen, and Podolsky on entanglement, intended to mean that quantum = entanglement is conveyed by General Relativity-style wormholes, so maybe = we'll find a way to use the entanglement wormholes to send add'l = information, but there's no evidence to suggest that's a possibility = today.=20 >=20 > Cheers, > Colin >=20 >=20 > -----Original Message----- >=20 > 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...) >=20 > Sorry for the tangent... >=20 > Regards > Sebastian >=20 > P.S.: Dave occasionally reminds us how 'slow' in comparison the speed = of sound is ~343 m/second (depending on conditions) or 343/1000 =3D = 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... >=20