[Starlink] The "reasons" that bufferbloat isn't a problem

Alexandre Petrescu alexandre.petrescu at gmail.com
Thu Jun 6 06:18:23 EDT 2024


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 at lang.hm>
> To: Alexandre Petrescu <alexandre.petrescu at gmail.com>
> Cc: Gert Doering <gert at space.net>, starlink at lists.bufferbloat.net
> Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem
> Message-ID: <1r928s39-s5o3-q44n-804n-11ro432210s8 at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink


More information about the Starlink mailing list