Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: David Lang <david@lang.hm>
Cc: Michael Richardson <mcr@sandelman.ca>, starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink and Iran
Date: Wed, 28 Jan 2026 16:09:10 +1300	[thread overview]
Message-ID: <3be747c6-793e-4b44-b1e1-52ee7ba9b6b0@auckland.ac.nz> (raw)
In-Reply-To: <32179q5n-7nr7-q861-4s70-337519804np5@ynat.uz>

On 20/01/2026 9:39 am, David Lang wrote:
> Ulrich Speidel wrote:
>
>> David Lang wrote:
>>> have you looked at what the latest changes allow?
>
>> No - if anyone has a pointer to what the official source for the 
>> latest SpaceX-FCC licensing interactions is ... I'd been hoping to 
>> figure that out but haven't yet.
>
> not much info here, but hopefully a start 
> https://www.fcc.gov/document/fcc-approves-next-gen-satellite-constellation
>
> A few days before this, spacex announced it was lowering the orbit for 
> ~4000 of it's satellites by ~70km
> https://www.space.com/space-exploration/satellites/spacex-lowering-orbits-of-4-400-starlink-satellites-for-safetys-sake 
>

OK, this took a moment. There are a few references to waivers of EPFD 
limits in the document but these needed a little research. The crux is 
in point 4 of the grant document, which makes reference to sections 
25.146(a)(2) and (c) of the FCC rules. Now 25.146(a)(2) references 
Article 22 and Resolution 76 of the ITU radio regulations. These impose 
EPFD limits on interference to geostationary systems from the aggregate 
operation of non-geostationary systems.

While these may or may not require SpaceX to stick to lower transmit 
power at times than the limits in Article 21 (which haven't been waived 
for all I can tell), it's the limits imposed by Article 21 that continue 
to put a lid on things.

So this doesn't look like good news in terms of being able to throttle up.

Either way, it's worth noting here that while the relationship between 
transmit power and and received power is linear, the relationship 
between received power and achievable bit rate is logarithmic in nature. 
For those not so mathematically inclined: Starlink is starting off with 
64QAM (6 bits per symbol) at current EPFD limits, and each extra bit 
beyond that requires a doubling of the received power. Turning up the 
volume is not a game you can stay ahead in for long, regardless of 
regulatory constraints.

Some interesting tidbits from the grant document though:

  * 4. a. No more than 8 satellite beams "in the same frequency" (I
    presume there's the word "band" missing here) into the same or
    overlapping areas at a time. That means at most 8 beams per cell.
  * 4. b. "SpaceX must maintain a minimum GSO arc exclusion zone of at
    least four (4) degrees with respect to operational GSO satellites".
    Finally a clear word?

-- 
****************************************************************
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/
****************************************************************



  reply	other threads:[~2026-01-28  3:09 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <176851123059.1249.8585659892308012167@gauss>
2026-01-15 21:49 ` [Starlink] Re: Starlink and Iran Colin_Higbie
2026-01-15 23:15   ` Frantisek Borsik
2026-01-16  0:13   ` Ulrich Speidel
2026-01-16  1:29     ` David Lang
2026-01-16 22:55       ` Frantisek Borsik
2026-01-16 23:06         ` J Pan
     [not found]     ` <13187.1768590201@obiwan.sandelman.ca>
2026-01-16 23:30       ` Ulrich Speidel
2026-01-17  0:07         ` David Lang
2026-01-17 21:56           ` Ulrich Speidel
2026-01-19 20:39             ` David Lang
2026-01-28  3:09               ` Ulrich Speidel [this message]
2026-01-28  3:30                 ` David Lang
2026-01-28  4:02                   ` Mike Puchol
2026-01-28  9:05                     ` Ulrich Speidel
2026-01-28  9:53                       ` David Lang
2026-01-28 20:43                         ` Ulrich Speidel
2026-01-28 20:55                           ` David Lang
2026-01-17 18:32         ` Michael Richardson
2026-01-17 18:38           ` Inemesit Affia
2026-01-17 19:25             ` Michael Richardson
2026-01-17 22:12           ` Ulrich Speidel
     [not found] <176849731431.1249.14387618908540773471@gauss>
2026-01-15 17:42 ` Colin_Higbie
2026-01-15 18:56   ` Jim Forster
2026-01-15 20:15     ` Ulrich Speidel
2026-01-15 20:27   ` Ulrich Speidel
2026-01-15 20:30     ` Hayden Simon
2026-01-15 21:06       ` Ulrich Speidel
2026-01-15 21:09         ` Hayden Simon
2026-01-15 21:20           ` Ulrich Speidel
2026-01-15 21:23             ` Hayden Simon
2026-01-15 14:50 David Fernández
2026-01-15 16:11 ` Oleg Kutkov
2026-01-15 17:13   ` J Pan
  -- strict thread matches above, loose matches on Subject: below --
2026-01-15  9:51 [Starlink] " Ulrich Speidel
2026-01-15 10:06 ` [Starlink] " Inemesit Affia
2026-01-15 10:30   ` Ulrich Speidel
2026-01-15 10:44     ` Inemesit Affia
2026-01-15 11:16       ` Ulrich Speidel
2026-01-15 10:32 ` Inemesit Affia
2026-01-15 10:51   ` Ulrich Speidel
2026-01-15 11:17 ` David Lang
2026-01-15 11:59   ` Sauli Kiviranta
2026-01-15 14:08     ` David Lang
2026-01-15 15:29       ` Sauli Kiviranta
     [not found]   ` <3af2ac06-e098-4c79-869d-9c389959ca07@gmail.com>
     [not found]     ` <q9304244-661o-3qsr-o6rp-9q1nqq09r419@ynat.uz>
     [not found]       ` <4ba64a41-bbbf-4fb5-adb0-c77c15e4ca0f@gmail.com>
2026-01-15 16:20         ` Inemesit Affia
2026-01-15 20:12   ` Ulrich Speidel
2026-01-15 17:10 ` J Pan
2026-01-15 20:07   ` Ulrich Speidel
2026-01-15 21:47     ` Oleg Kutkov
2026-01-16  4:18       ` Ulrich Speidel
2026-01-16  8:12         ` Frantisek Borsik
2026-01-16  8:24           ` Inemesit Affia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3be747c6-793e-4b44-b1e1-52ee7ba9b6b0@auckland.ac.nz \
    --to=u.speidel@auckland.ac.nz \
    --cc=david@lang.hm \
    --cc=mcr@sandelman.ca \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox