[Starlink] I had forgotten how good this was

Wed Jan 22 19:26:25 EST 2025

On 23/01/2025 11:52 am, Dave Taht via Starlink wrote:
> On Mon, Jan 20, 2025 at 11:36 PM Mike Puchol via Starlink
> <starlink at lists.bufferbloat.net> wrote:
>> Thank you Dave!
>>
>> It has been a while since I wrote that piece, and so much has changed. I have been really busy with work, and haven’t been able to implement a lot of these changes into the starlink.sx tracker - I’m trying to put aside some time to update it.
> Perhaps someone here could help you out?

There are a number of issues that were not addressed in Mike's original 
paper:

  * Beam shaping
  * ITU EPFD limits. These cap what can go to all dishys in a cell to
    <=12 Gb/s combined if the cell is served exclusively from the Gen 1
    generation and <=20 Gb/s if only Gen 2 is used, inclusive of any
    overhead (FEC, access/handover management). So the real cell
    capacity per dishy is usually somewhere between these numbers.
    That's provided SpaceX stick to what they applied for in terms of
    the licenses they were seeking. In that sense, it doesn't matter
    whether sats are brought down further. As long as these limits are
    in place (and removing them completely might just jeopardise
    people's satellite TV), about the only way to add capacity is to
    have more cells per surface area (=fewer users per cell), i.e., make
    the cells and beam footprints smaller, and that becomes increasingly
    non-trivial as cell size shrinks.
  * v2 didn't apply for division of Ku band into sub-channels, so
    there's a bit of extra capacity there in terms of straddled guard
    bands - potentially.
  * E and Ka aren't used for end user downlink (and wouldn't be suitable
    for such on a continuous basis due to fading in rain etc.)
  * Ka-band community gateways

We're about to submit a couple of papers to address some of this. Quite 
which cell gets how much of the cake based on local quirks - which is 
what Mike mostly looked into - we're not addressing, however, at least 
not for any particular cell.

It would generally help if people understood that when someone talks 
about speeds or capacity in relation to Starlink, then it's usually 
meaningless unless they say exactly what capacity they mean:

  * Capacity / speed to / from individual user?
  * Capacity / speed to / from individual cell? Cell where? Cell in
    which neighbourhood context (any dishys in the neighbourhood)?
  * Capacity of satellite to all dishy users in FOV combined?
  * Capacity of all beams (including sat to / from gateways) on a
    satellite?
  * Capacity in sky seen by a dishy (only part of which may be
    deployable to the cell that the dishy is in, but which acts as an
    indicator of whether the cell is likely to get as much as spectrum
    permits)
  * Capacity of optical links.
  * Total system capacity worldwide.

These are all totally different, dependent on generation of satellite 
and latitude, and in a lot of cases on more than just your dishy and the 
one satellite it's talking to at the moment. Yet our influencer friends 
seem to be only too happy to post numbers without context, and then they 
cause a flurry when they get re-posted here.

It's also important to remember that the maximum achievable physical 
layer data rates aren't the only factor in how well a connectivity 
solution works and how scalable it is. Bufferbloat's been discussed here 
extensively, but the thing that I'm almost more concerned about is the 
absence of an obvious way of running a CDN on/via/for a LEO network. 
This means that a big chunk of the collective physical capacity of 
Starlink gets spent on transmitting the same content to large numbers of 
users one user at a time: Each user needs their own copy communicated to 
them, and it takes up capacity every single time. This is fundamentally 
different from what happens on international fibre cables now.

Did those of you in the Seattle to Portland (OR) corridor, those around 
Sacramento (CA) and San Diego (CA), those around Edmonton (Canada), Rio 
de Janeiro and Sao Paolo, London (UK), Manila, Jakarta, Brisbane, Perth, 
Harare, Abuja, Accra, Port Harcourt and a whole bunch of other places 
notice that you can no longer get a fixed address Starlink connection 
there? Sold out, and not for lack of dishys, I guess.

>
>> The following I can think of:
>>
>> v2mini satellites are not modeled, and are now a great portion of the constellation.
>> Gateways now have Ka and E band capability, increasing backhaul capacity considerably (5 GHz available on E band).
> I am under the impression that much of the rocky mountains - eastern
> USA can only be served by E and Ka and not Ku?
>
>> Several megasites have been constructed (32 gateway antennas per site).
>> Additional Ku beams are available on v2mini satellites.
>> ISL is a complete mesh now, with very few gaps.
> I keep wondering what tokoyo to london latency is via ISL.
>
>> DTC onboard newer v2mini satellites.
>> Reduced operational altitude on some shells, enabling more frequency re-use, and 3-4 dB better link margin.
>> New versions of the UT, with Mini being the equivalent of 802.11b Wi-Fi clients ruining the party for G/N clients by dragging down resources.
> I thought this would really hurt the constellation initially, but if
> you consider most of the time
> a dish is idle, not so much.
>>
>>
>> Best,
>>
>> Mike
>> On Jan 14, 2025 at 14:24 -0800, Dave Taht via Starlink<starlink at lists.bufferbloat.net>, wrote:
>>
>> https://mikepuchol.com/modeling-starlink-capacity-843b2387f501
>>
>> It has a few challengeable assumptions now.
>>
>> --
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at 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 at auckland.ac.nz 
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20250123/b70c2109/attachment.html>