* Re: [Starlink] I had forgotten how good this was
2025-01-22 22:52 ` Dave Taht
@ 2025-01-23 0:26 ` Ulrich Speidel
0 siblings, 0 replies; 5+ messages in thread
From: Ulrich Speidel @ 2025-01-23 0:26 UTC (permalink / raw)
To: starlink
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread