<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 23/01/2025 11:52 am, Dave Taht via
Starlink wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA93jw7o69iwzK0RUqxVuWHbpVN1ybqGmh+BTdHm=0u2qStz1w@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">On Mon, Jan 20, 2025 at 11:36 PM Mike Puchol via Starlink
<a class="moz-txt-link-rfc2396E" href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Perhaps someone here could help you out?</pre>
</blockquote>
<p>There are a number of issues that were not addressed in Mike's
original paper:</p>
<ul>
<li>Beam shaping</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>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.)</li>
<li>Ka-band community gateways</li>
</ul>
<p>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.</p>
<p>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:</p>
<ul>
<li>Capacity / speed to / from individual user?</li>
<li>Capacity / speed to / from individual cell? Cell where? Cell
in which neighbourhood context (any dishys in the
neighbourhood)?<br>
</li>
<li>Capacity of satellite to all dishy users in FOV combined?</li>
<li>Capacity of all beams (including sat to / from gateways) on a
satellite? <br>
</li>
<li>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) <br>
</li>
<li>Capacity of optical links.<br>
</li>
<li>Total system capacity worldwide.</li>
</ul>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<blockquote type="cite" cite="mid:CAA93jw7o69iwzK0RUqxVuWHbpVN1ybqGmh+BTdHm=0u2qStz1w@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
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).
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
I am under the impression that much of the rocky mountains - eastern
USA can only be served by E and Ka and not Ku?
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
I keep wondering what tokoyo to london latency is via ISL.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
I thought this would really hurt the constellation initially, but if
you consider most of the time
a dish is idle, not so much.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
Best,
Mike
On Jan 14, 2025 at 14:24 -0800, Dave Taht via Starlink <a class="moz-txt-link-rfc2396E" href="mailto:starlink@lists.bufferbloat.net"><starlink@lists.bufferbloat.net></a>, wrote:
<a class="moz-txt-link-freetext" href="https://mikepuchol.com/modeling-starlink-capacity-843b2387f501">https://mikepuchol.com/modeling-starlink-capacity-843b2387f501</a>
It has a few challengeable assumptions now.
--
Dave Täht CSO, LibreQos
_______________________________________________
Starlink mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/starlink">https://lists.bufferbloat.net/listinfo/starlink</a>
_______________________________________________
Starlink mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Starlink@lists.bufferbloat.net">Starlink@lists.bufferbloat.net</a>
<a class="moz-txt-link-freetext" href="https://lists.bufferbloat.net/listinfo/starlink">https://lists.bufferbloat.net/listinfo/starlink</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
****************************************************************
Dr. Ulrich Speidel
School of Computer Science
Room 303S.594 (City Campus)
The University of Auckland
<a class="moz-txt-link-abbreviated" href="mailto:u.speidel@auckland.ac.nz">u.speidel@auckland.ac.nz</a>
<a class="moz-txt-link-freetext" href="http://www.cs.auckland.ac.nz/~ulrich/">http://www.cs.auckland.ac.nz/~ulrich/</a>
****************************************************************
</pre>
</body>
</html>