[Starlink] I had forgotten how good this was

[Starlink] I had forgotten how good this was

[Dave Taht]

https://mikepuchol.com/modeling-starlink-capacity-843b2387f501

It has a few challengeable assumptions now.

-- 
Dave Täht CSO, LibreQos

Re: [Starlink] I had forgotten how good this was

[Brandon Butterworth]

saw this, thought oh that's awfully nice of them to go
to all that bother

https://x.com/SpaceBiz1/status/1880601039386141049
https://orbitaltoday.com/2025/01/15/spacex-tests-solution-to-starlink-satellites-interferening-with-on-ground-astronomy/

then saw these:

https://x.com/CatSE___ApeX___/status/1880640102889849065
"Nothing to do with astronomers.
Replenishrate down there is very expensive. Very frequent
beam to beam handovers. They’re forced. BC of a) Harq ACK
timeout (they don’t have ASTs patented trick) and b) FCC
throttled their power due to bad ACLR and nonexistent
sidelobe mitigation."

https://x.com/Megaconstellati/status/1880643289897894228
"Note that this is for the SpaceX Gen 2 satellites which ar
Ku-band broadband satellites, not D2D, the latter which
have never done their orbital raising but remained in
VLEO - most likely for the reason you mention"

brandon

Re: [Starlink] I had forgotten how good this was

[Mike Puchol]

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

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.

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).
• 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.
• 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.



Best,

Mike
On Jan 14, 2025 at 14:24 -0800, Dave Taht via Starlink <starlink@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

Re: [Starlink] I had forgotten how good this was

[Dave Taht]

On Mon, Jan 20, 2025 at 11:36 PM Mike Puchol via Starlink
<starlink@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?

>
> 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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
Dave Täht CSO, LibreQos

Re: [Starlink] I had forgotten how good this was

[Ulrich Speidel]

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

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@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@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@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: 8841 bytes --]