Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Mike Puchol <mike@starlink.sx>
To: starlink@lists.bufferbloat.net
Cc: Michael Richardson <mcr@sandelman.ca>, David Lang <david@lang.hm>,
	Ulrich Speidel <u.speidel@auckland.ac.nz>
Subject: [Starlink] Re: Starlink and Iran
Date: Tue, 27 Jan 2026 20:02:46 -0800	[thread overview]
Message-ID: <9c6dfe32-da45-45ca-ab33-5ea031b5d2a5@Spark> (raw)
In-Reply-To: <o7o2spor-3o39-o594-r163-q0n5p2o8or25@ynat.uz>

One clarification, nco = 8 means 8 co-frequency beams overlapping. If you have 8 different channels in Ku band, that’s a total of 64 possible beams per cell. This is a huge upgrade from the original nco = 1 for user/service beams (e.g. max 8 beams per cell).

Best,

Mike
On Jan 27, 2026 at 19:30 -0800, David Lang via Starlink <starlink@lists.bufferbloat.net>, wrote:
> Ulrich Speidel wrote:
>
> > 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.
>
> I think that the value in allowing higher radiated power at the receive end
> isn't to increase the bit rate from a single satellite, but to allow multiple
> satellites to cover the same area with the beam steering on the receiver
> differentiating between the satellites.
>
> allowing two satellites with significantly different angles to cover the same
> area allows for (close to) 2x the aggregate bandwidth to spread between all
> receivers in that area.
>
> > 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.
>
> if that's a step up from a single beam, that will allow for close to 8x the
> aggregate bandwidth.
>
> And if they can show (over time) that this doesn't cause problems, it will be
> reasonable to expect raising this limit over time
>
> it may be band, or it may be frequency/channel (like wifi has 3 bands, 2.4G, 5G,
> 6G), but 5G has many non-overlapping channels, and operating on multiple
> channels at the same time is quite reasonable for high-end APs
>
> > * 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?
>
> that geo exclusion has been in place for a while, but I thought it was a lot
> wider than 8 degrees (4 degrees to each side) I seem to remember hearing 25
> degrees being thrown around in discussions (I may very well be misremembering)
>
> David Lang
> _______________________________________________
> Starlink mailing list -- starlink@lists.bufferbloat.net
> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

  reply	other threads:[~2026-01-28  4:03 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
2026-01-28  3:30                 ` David Lang
2026-01-28  4:02                   ` Mike Puchol [this message]
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=9c6dfe32-da45-45ca-ab33-5ea031b5d2a5@Spark \
    --to=mike@starlink.sx \
    --cc=david@lang.hm \
    --cc=mcr@sandelman.ca \
    --cc=starlink@lists.bufferbloat.net \
    --cc=u.speidel@auckland.ac.nz \
    /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