From: Colin_Higbie <CHigbie1@Higbie.name>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Subject: [Starlink] 300ms Telecommunication Latency and FTL Communication
Date: Wed, 5 Jun 2024 17:58:50 +0000 [thread overview]
Message-ID: <MN2PR16MB33919BA5D364FA41ED20CD49F1F92@MN2PR16MB3391.namprd16.prod.outlook.com> (raw)
In-Reply-To: <mailman.3171.1717601612.1074.starlink@lists.bufferbloat.net>
Sebastian,
At 300ms RTT, that would mean the starting point for any communications are already at the threshold of unacceptability. 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.
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.
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.
Best I've heard on this is the somewhat-famous-in-Physics-circles hypothesis that ER = EPR, referring to the paper by Einstein and Rosen on wormholes (the Einstein-Rosen bridge) = 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.
Cheers,
Colin
-----Original Message-----
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...
next parent reply other threads:[~2024-06-05 17:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.3171.1717601612.1074.starlink@lists.bufferbloat.net>
2024-06-05 17:58 ` Colin_Higbie [this message]
2024-06-06 7:22 ` Sebastian Moeller
2024-06-06 13:43 ` Colin_Higbie
2024-06-07 14:07 ` Sebastian Moeller
2024-06-07 14:55 ` David Lang
2024-06-07 15:32 ` Sebastian Moeller
2024-06-07 16:46 ` Colin_Higbie
2024-06-07 16:56 ` David Lang
2024-06-07 17:00 ` Colin_Higbie
2024-06-07 17:34 ` Michael Richardson
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=MN2PR16MB33919BA5D364FA41ED20CD49F1F92@MN2PR16MB3391.namprd16.prod.outlook.com \
--to=chigbie1@higbie.name \
--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