Re: [Starlink] musk: 28ms median latency on starlink

[Ulrich Speidel <u.speidel@auckland.ac.nz>]

[-- Attachment #1: Type: text/plain, Size: 7403 bytes --]

On 4/06/2024 5:41 am, Mike Puchol wrote:
> While the terminals use focused beams, Starlink does not operate in 
> isolation or using protected spectrum. They must comply with EPFD 
> limits, which are the reason why they just cannot land two 
> co-frequency beams that overlap, as they could be causing harmful 
> interference to other users of the same spectrum.

Precisely.

Likewise, the famous "25 degrees over the horizon" isn't a nod to "too 
many trees/houses around Dishy", but there to satisfy the regulators 
that a transmitting beam from a satellite won't get into (more or less 
horizontally pointing) terrestrial communication systems (there's a 
softening of that requirement to 5 degrees minimum for beams to gateways 
at higher latitudes only).

It's also notable that this EPFD limit leads to a de-facto 
standardisation of the downlink as such. In a "textbook" system, you'd 
have some transmit power on the satellite, some antenna gain up there, 
you'd then take into account the path loss from spherical spreading of 
the signal on its way down, which gives you a PFD at your receiver site 
that depends on the geometry of the satellite-ground station 
arrangement. You'd then also look at your receive antenna gain. That's 
determined by the antenna aperture, which in the case of a phased array, 
is the collective area of all antenna elements. And since you're 
steering your receive beam, you'd be downrating the aperture by the 
cosine of your steering angle. And then you'd end up with some signal to 
noise ratio at the receiver which determines what modulation scheme you 
can use, and that along with the bandwidth of the link determines your 
capacity. But now you have a hard limit on your PFD imposed by the 
regulatory EPFD limit. So what SpaceX do according to their FCC filings 
is to reduce their EIRP at the satellite so the signal stays under/at 
the EPFD limit on the Earth's surface, and they adjust Dishy gain by 
using fewer of its elements the lower their steering angle is.

Put in another way:  If you could "see" Starlink satellite signals, they 
would appear equally bright to you no matter where in the sky they come 
from - you wouldn't be able to tell distance from brightness. Similarly, 
you could think of Dishy as a pair of sunglasses that are tinted most 
strongly in the middle but where the tinting fades as you look sideways. 
Sounds complex but results in SNR's that are a perfect fit for the 
modulation schemes (16QAM for Gen 1, 64QAM / 256QAM for Gen 2), so saves 
on satellite and Dishy having to negotiate modulation.

>
> Best,
>
> Mike
> On Jun 3, 2024 at 09:43 -0700, David Lang via Starlink 
> <starlink@lists.bufferbloat.net>, wrote:
>> If the ground stations were omnidirectional antennas, you would be 
>> correct, but
>> since they are phased array directional antennas, they can steer the 
>> beam to
>> receive one satellite even while a different one is transmitting on 
>> the same
>> frequency to the same cell.
>>
>> David Lang
>>
>>
>> On Mon, 3 Jun 2024, Ulrich Speidel via Starlink wrote:
>>
>>> Date: Mon, 3 Jun 2024 22:40:24 +1200
>>> From: Ulrich Speidel via Starlink <starlink@lists.bufferbloat.net>
>>> Reply-To: Ulrich Speidel <u.speidel@auckland.ac.nz>
>>> To: starlink@lists.bufferbloat.net
>>> Subject: Re: [Starlink] musk: 28ms median latency on starlink
>>>
>>> Getting the satellite density up will help, but it will only improve 
>>> things
>>> so far.
>>>
>>> The problem on user downlink in particular is that there's a limit 
>>> on the
>>> maximum spectral power flux density that arrives from the satellite 
>>> in space
>>> on the ground. If you point all (mutually compatible) user downlink 
>>> beams
>>> from a single satellite at a single cell, you all but reach that 
>>> limit there.
>>> In fact, where SpaceX want to use two beams on the same frequency 
>>> but with
>>> opposite polarisations to the same cell, they must reduce the 
>>> transmit power
>>> on each beam by 3 dB (50%) in order to stay within the limit. More 
>>> satellites
>>> would give you more beams, but you can't point them at cells that 
>>> already
>>> have a beam on the same frequency in use from another satellite 
>>> (unless you
>>> de-rate on the power front, I guess). That seriously limits what you can
>>> receive in terms of total capacity within a single cell to what a single
>>> satellite's mutually compatible beams can deliver, which appears to 
>>> be about
>>> 12 Gb/s on V1 and V1.5 birds, and 20 Gb/s on V2 (on Ku, if you add 
>>> in Ka-band
>>> and anticipate Dishys that can do Ka, then it's a lot more for Ka). In
>>> practice, we know that a cell gets served by beams from different 
>>> satellites,
>>> but the overall constraint still applies - if you deploy beam X from 
>>> sat A
>>> and beam Y from sat B to the same cell, this makes the same 
>>> contribution to
>>> PFD as deploying both from the same satellite. Note that Starlink 
>>> sats do
>>> have multiple mutually incompatible beams that they can only point at
>>> different cells, bringing Ku user downlink capacity up to 16 Gb/s on 
>>> V1 and
>>> 1.5, and 48 Gb/s on V2. But that only ups your chances of getting a 
>>> larger
>>> slice of those 12 or 20 Gb/s in your cell.
>>>
>>> Your best bet for continuing good service at the moment is literally 
>>> to tell
>>> your neighbours that Starlink is useless, so they don't sign up and 
>>> you can
>>> have your cake all to yourself ;-)
>>>
>>> On 3/06/2024 5:13 am, Dave Taht via Starlink wrote:
>>>> Via elon musk:
>>>>
>>>> Starlink just achieved a new internal median latency record of 28ms
>>>> yesterday! Great work by the engineering and operations teams.
>>>>
>>>> - https://twitter.com/elonmusk/status/1797282250574184587
>>>>
>>>> I of course, am very interested in y'all´s external measurements of how
>>>> well starlink is doing. For me, it is fantastic - 30Mbit uploads 
>>>> nowadays,
>>>> 0
>>>> latency on the upload (how?)
>>>> https://www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe
>>>>
>>>> I also keep hoping that the rest of the ISP industry is now paying
>>>> attention and deploying stuff like fq_codel and cake and libreqos, 
>>>> but, ah
>>>> well - I will settle for starlink blowing past a lot of dsl and 
>>>> cable and
>>>> finding ways to get their density up.
>>>>
>>>> Anyone going to the Starship launch on the 6th?
>>>>
>>>>
>>>>
>>>> --
>>>> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s
>>>> <https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s> Waves Podcast
>>>> Dave Täht CSO, LibreQos
>>>>
>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 11592 bytes --]