From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
Date: Thu, 6 Jun 2024 12:18:23 +0200 [thread overview]
Message-ID: <2bbb7c1f-f8bc-44eb-9348-7d82af8b4309@gmail.com> (raw)
In-Reply-To: <CAC=tZ0rTWzp+g26RH=wkuyaHnCHzgV1Fno80LNxOxmQv-cLbtw@mail.gmail.com>
Le 05/06/2024 à 16:46, David Fernández via Starlink a écrit :
> "quantum entanglement may be a path to beat the speed of light"
>
> It seems that is not going anywhere. Maybe better warp drives.
>
> Faster than light comms as a target for 7G mentioned here:
> https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440
> <https://imageio.forbes.com/specials-images/imageserve/653fee7b042dc92df0919930/MnM-Trends-Wheel/960x0.jpg?format=jpg&width=1440>
>
> https://www.forbes.com/sites/sarwantsingh/2023/10/30/the-mega-trends-that-will-shape-our-future-world
>
> So, maybe that means that 6G will be the last G, after all, as faster
> than light comms seem to be impossible, because paradoxes could be
> created.
It can be an interesting discussion whether or not 6G, and 5G for that
matter, is the last G, as we know these Gs.
Some take a prudent stance and talk about a _next_ G, as it might always
be possible to plan about a next version.
The latency decrease in these Gs (mobile comm generations) will
continue, forever chasing the Ethernet latencies, maybe in a nano-second
class today. At the current speed of latency decrease (500ms 2.5G,
100ms 3G, 50ms 4G, 10ms 5G) one can safely assume a 250micro-second 9G
in year 2040 or so.
The decrease of latency in Gs is not a matter of physics limitations
such as distance or energy. The typical G latency happens mostly
between a 'tower' and a smartphone on the 'air interface'. The way the
bits are stuffed in there is what makes that latency higher or lower.
There can be very much additional simultaneity beyond what MIMO does,
smarter error correction, interference avoidance and so on. In theory,
one might even reach an almost infinitely low (epsilon) latency, i.e. a
latency that is that low that goes beyond the imediateness that we feel
when sensing the nature.
The breaks in the G sequence might arise from voluntary decrease in
energy consumption to reduce climate change, human-generated but hard to
understand catastrophic events, or personal inability to settle on
standards because of beliefs or ideology. But there is no physics
limitation in the G increase.
>
> The end of comms engineering could be in the horizon of our lifetime.
In a sense, one would be happy to have all the communication standards
frozen so all is settled and universal interoperability is ensured for
years. A little bit like bridges are there for hundreds of years,
except some, of course.
Alex
>
>
> Date: Wed, 5 Jun 2024 07:16:16 -0700 (PDT)
> From: David Lang <david@lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: Gert Doering <gert@space.net>, starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8@ynat.uz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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.
>
> David Lang
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
next prev parent reply other threads:[~2024-06-06 10:18 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 14:46 David Fernández
2024-06-05 14:57 ` Vint Cerf
2024-06-06 17:12 ` Michael Richardson
2024-06-06 10:18 ` Alexandre Petrescu [this message]
2024-06-06 10:37 ` Aidan Van Dyk
2024-06-06 10:33 ` Alexandre Petrescu
-- strict thread matches above, loose matches on Subject: below --
2024-06-07 7:36 David Fernández
2024-06-05 15:16 David Fernández
2024-06-05 15:21 ` Bless, Roland (TM)
2024-06-05 15:32 ` David Fernández
2024-06-05 16:24 ` Sebastian Moeller
2024-06-06 23:10 ` Michael Richardson
2024-06-07 1:39 ` David Lang
2024-06-07 6:20 ` Sebastian Moeller
2024-06-07 17:41 ` Eugene Y Chang
2024-06-07 17:51 ` David Lang
2024-06-07 20:09 ` Eugene Y Chang
2024-06-08 1:53 ` David Lang
2024-06-05 16:23 ` Sebastian Moeller
2024-06-06 7:07 ` David Fernández
2024-06-06 7:41 ` Sebastian Moeller
2024-05-08 9:31 David Fernández
2024-05-07 12:13 David Fernández
2024-05-07 12:46 ` Dave Collier-Brown
2024-05-07 19:09 ` Eugene Y Chang
2024-05-07 19:11 ` Dave Taht
2024-05-07 19:14 ` Jeremy Austin
2024-05-07 19:46 ` Dave Taht
2024-05-07 20:03 ` Eugene Y Chang
2024-05-07 20:05 ` Frantisek Borsik
2024-05-07 20:25 ` Eugene Y Chang
[not found] <mailman.2773.1714488060.1074.starlink@lists.bufferbloat.net>
2024-04-30 18:05 ` [Starlink] It’s the Latency, FCC Colin_Higbie
2024-04-30 19:04 ` Eugene Y Chang
2024-05-01 0:36 ` David Lang
2024-05-01 1:30 ` [Starlink] Itʼs " Eugene Y Chang
2024-05-01 1:52 ` Jim Forster
2024-05-01 3:59 ` Eugene Y Chang
2024-05-01 4:12 ` David Lang
2024-05-01 18:51 ` Eugene Y Chang
2024-05-01 19:18 ` David Lang
2024-05-01 21:12 ` Eugene Y Chang
2024-05-01 21:27 ` Sebastian Moeller
2024-05-01 22:19 ` Eugene Y Chang
2024-05-06 11:25 ` [Starlink] The "reasons" that bufferbloat isn't a problem Rich Brown
2024-05-06 12:11 ` Dave Collier-Brown
2024-05-07 0:43 ` Eugene Y Chang
2024-05-07 12:05 ` Dave Collier-Brown
[not found] ` <CAJUtOOhH3oPDCyo=mk=kwzm5DiFp7OZPiFu+0MzajTQqps==_g@mail.gmail.com>
2024-05-06 19:47 ` Rich Brown
2024-05-07 0:38 ` Eugene Y Chang
2024-05-07 10:50 ` Rich Brown
2024-05-08 1:48 ` Dave Taht
2024-05-08 7:58 ` Frantisek Borsik
2024-05-08 8:01 ` Frantisek Borsik
2024-05-08 18:29 ` Eugene Y Chang
2024-06-04 18:19 ` Stuart Cheshire
2024-06-04 20:06 ` Sauli Kiviranta
2024-06-04 20:58 ` Eugene Y Chang
2024-06-05 11:36 ` Alexandre Petrescu
2024-06-05 13:08 ` Aidan Van Dyk
2024-06-05 13:28 ` Alexandre Petrescu
2024-06-05 13:40 ` Gert Doering
2024-06-05 13:43 ` Alexandre Petrescu
2024-06-05 14:16 ` David Lang
2024-06-05 15:10 ` Sebastian Moeller
2024-06-05 16:21 ` Alexandre Petrescu
2024-06-05 19:17 ` Eugene Y Chang
2024-06-04 23:03 ` Rich Brown
2024-06-06 17:51 ` Stuart Cheshire
2024-06-07 2:28 ` Dave Taht
2024-06-07 5:36 ` Sebastian Moeller
2024-06-07 7:51 ` Gert Doering
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=2bbb7c1f-f8bc-44eb-9348-7d82af8b4309@gmail.com \
--to=alexandre.petrescu@gmail.com \
--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