Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Mike Puchol <mike@starlink.sx>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink "beam spread"
Date: Tue, 30 Aug 2022 22:09:28 +0200	[thread overview]
Message-ID: <7b7bff13-b0ef-41ad-9a40-d12bfe5a0dfe@Spark> (raw)
In-Reply-To: <A80186F8-CC55-4DF3-84C0-98883E2A9737@searls.com>

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

Given that I may have triggered this, and with my limited understanding of how Starlink is put together from a resource allocation standpoint, first, some caveats:

• A simulation without inside knowledge is always going to be an approximation. In my case, it’s usually the best-case scenario.
• The simulation of a country should not be done in isolation to increase realism. Many of the satellites over the northern US are also serving Canada, which means there are less resources available to US cells than the simulation portrays.
• The real constellation would allocate resources based on demand, primarily, and Starlink knows said demand quite accurately (once ESIMs are in place, this will change!). Thus, cells which are in very densely populated areas, which I include, would likely receive very few resources, if any. Many empty cells or those with no customers won’t receive resources either.

Starlink has essentially these mechanisms to increase the number of cells covered by the constellation at any given time (others like number of beams are fixed in hardware):

• TDM aka beamhopping: split 100% of “airtime” into frames, and allocate certain number of frames to more than one cell. Can provide asymmetric capacity based on demand per cell. The switching time from cell to cell is the driver for how far you can split the beam in the time domain, before the switching overhead starts killing performance.

• Beam spread: as the beam is steered away from nadir, it becomes larger and elliptical, thus covering more than one cell (apart from the target cell). Allows to split the beam resources allocated to the center cell amongst all other cells in the FOR (field of regard). Cannot be asymmetric without enforcing terminal discipline, where each terminal is receiving 100% of the downlink (which could be 10% of the full beam if TDM splits into 10 cells), but is only grabbing what is addressed to it specifically (akin to an LTE network).

• Multiple beams over a single cell: up to eight spot beams can be projected onto a single cell without running into EPFD limits, as long as each one uses one of the eight frequencies available. These simultaneous beams could come from one or more satellites. This is how you can get additional capacity to a cell, for example, to compensate for reduction by TDM. Two beams at 50% duty cycle make up for one full beam. The advantage is spatial diversity, where a terminal that has one satellite obstructed could opt from a beam from a different, non-obstructed satellite.

We must also understand provisioned vs. advertised capacity. In Kenya, we provision 1.5 Mbps per customer, but advertise and sell a 5 Mbps service. Actual average per customer is 1.2 Mbps. If we took a single beam capable of 700 Mbps (many observations and circumstantial evidence support this figure), at 1.5 Mbps provisioned it would serve ~466 customers. Once you start applying TDM, beam spread, etc. the number reduces, and can only be compensated by adding additional beams. It’d be interesting to hear what ISPs in the US provision their customers with.

Of course fiber is the top option if you can get it economically, but if there are vast regions of the US (not considered a developing country) still not serviced by it, or even by fast WISPs, then there are reasons to look for alternatives - I’m willing to bet a financial analysis doesn’t warrant laying thousands of kilometers of fiber to serve relatively few customers. Starlink is providing significant service levels to people who could only dream, with all its growing pains and inefficiencies.

If you start talking about “connecting the unconnected” (a kitten dies every time that one is said), then fiber is one option, but it becomes more relevant for major backhaul, not even middle or last mile. People who have a disposable income of $1 to $5 per month just cannot be serviced by a financially viable service that relies on fiber. Here, you need to start getting creative.

Best,

Mike
On Aug 30, 2022, 19:32 +0200, Doc Searls via Starlink <starlink@lists.bufferbloat.net>, wrote:
> All good points.
>
> I'm also wondering if (and how) Starlink is improving any satellite gear in successive launches. And, if that's the case, what would be the upper limit to what's possible with the system?
>
> I ask the first question because Starlink has been deorbiting quite a few satellites...
>
> https://spacenews.com/spacex-launches-starlink-satellites-as-it-deorbits-original-ones/
>
> https://www.space.com/spacex-starlink-satellite-deorbit-video
>
> ... while launching many new ones.
>
> For example, there will be a Falcon launch from Vandenberg, of several dozen satellites, at 10:30 (or :40) PM Pacific time on Wednesday night (though there are conflicting reports, and launches often get canceled):
>
> https://www.edhat.com/news/spacex-starlink-launch-rescheduled-for-tuesday
>
> https://www.spacelaunchschedule.com/category/vandenberg-sfb/
>
> https://www.space.com/spacex-starlink-group-3-4-launch-rocket-landing
>
> https://www.ksby.com/news/local-news/spacex-targets-tuesday-night-for-falcon-9-launch-of-starlink-satellites
>
> A late evening launch time makes for good viewing because it's dark enough to see the launch from a distance, and the rocket hits sunlight at the edge of space, where exhaust moves outward in all directions uncontained by atmosphere, leaving a tubular trail in the sky.
>
> Here is a collection of screen grabs from a camcorder recording of a launch in 2005: https://www.flickr.com/photos/docsearls/albums/999576 This launch will be later in the evening, but still quite visible. One big difference will be the return trip of the first stage to a platform out in the ocean. I caught one of those in this series of shots here: https://www.flickr.com/photos/docsearls/albums/72157701027229232
>
> (Forgive my indulgence in space-freakery. I do enjoy this stuff, and I'm not here in Santa Barbara often enough. But I am here now, so I'll be shooting it again, this time with a new camera and a longer lens.)
>
> Doc
>
> > On Aug 30, 2022, at 9:53 AM, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:
> >
> > I have no clue why this matters (other than this is in color).
> >
> > The phased array antennas used by Starlink are quite limited - in particular, there are 4 on each satellite and each earth-ground path is half-duplex, TDM, essentially. Limited by hardware. The problem of signal equalization and quantization limits prevent "space division multiplexing" and "frequency division multiplexing" in practice.
> >
> > The 4 msec "turnaround time" at the physical level (satellite) means that time from a packet arriving at one end to be sent to the other end of the sat-dishy links gets worse the more dishys are served by one of the 4 antennas on the satellite.
> >
> > trying to increase the coverage of an individual satellite basically means serving more dishys per satellite, with less total bit rate, and much longer latency due to the half duplexness.
> >
> > Now if the total bit rate of a sat-to-dishy link were, say, 1 Gigabit, like an 802.11ac AP gives you, and the turnaround time were under 1 microsecond rather than 4 msec. maybe then you could get reasonable Internet service to dishys.
> >
> > But 240 Mb/s or 172 Mb/s as proposed for getting a bit more coverage per satellite? This is nowhere near competitive with what we expect in the US.
> >
> > Sorry to rain on all the techy dreaming.
> >
> > First, it's worth looking at all the problems currently in WiFi performance when you share an AP with multiple active stations using 100's of Gb/s on the average (not just occasionally).
> >
> > Dave - you tried in "make-wifi-fast", and the architecture gets in the way there. (yeah you can get point to point gigabit/sec single file transfers, but to do that you invoke features that destroy latency and introduce huge variability if you share the AP at all, for these reasons).
> >
> > Starlink is a good "last resort" service as constituted. But fiber and last few-hundred meters wireless is SO much better able to deliver good Internet service scalably.
> > Even that assumes fixing the bufferbloat that the Starlink folks don't seem to be able to address...
> > _______________________________________________
> > 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

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

  reply	other threads:[~2022-08-30 20:09 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1661875202.32670.starlink@lists.bufferbloat.net>
2022-08-30 16:53 ` David P. Reed
2022-08-30 17:32   ` Doc Searls
2022-08-30 20:09     ` Mike Puchol [this message]
2022-08-30 20:35       ` Daniel AJ Sokolov
2022-08-30 20:40         ` Mike Puchol
2022-08-30 21:09       ` David Lang
2022-08-30 21:01   ` David Lang
2022-08-30 22:07     ` Brandon Butterworth
2022-08-30 22:21       ` David Lang
2022-08-30 22:37         ` Brandon Butterworth
2022-08-30 23:07           ` David Lang
2022-08-30 23:45             ` Brandon Butterworth
2022-08-30 23:28           ` David P. Reed
2022-08-31  0:12             ` David Lang
2022-08-31  0:31               ` Dave Taht
2022-08-31  0:32               ` David P. Reed
2022-08-31 10:29                 ` Dave Collier-Brown
2022-08-31 18:51                   ` David Lang
2022-08-31 19:04             ` Dave Taht
2022-08-30 22:50       ` Ulrich Speidel
2022-08-30 23:13         ` David Lang
2022-08-31  0:46         ` tom
2022-08-31  0:58           ` Dave Taht
2022-08-31  7:36             ` Mike Puchol
2022-08-31  6:26         ` Sebastian Moeller
2022-08-31  7:25           ` Ulrich Speidel
2022-08-31  7:31             ` Hayden Simon
2022-08-31  7:33             ` David Lang
2022-08-31  9:59               ` Mike Puchol
2022-08-31 10:06                 ` David Lang
2022-08-31 10:12                   ` Mike Puchol
2022-08-31 17:52                 ` Dick Roy
2022-08-31 13:41               ` Ulrich Speidel
2022-08-31 14:30                 ` Mike Puchol
2022-08-31 21:44                   ` Ulrich Speidel
2022-09-01  7:58                 ` Sebastian Moeller
2022-09-01 11:38                   ` Ulrich Speidel
2022-09-01 19:54                     ` Michael Richardson
2022-09-01 21:08                       ` tom
2022-09-02  7:52                         ` Sebastian Moeller
2022-09-02 12:29                           ` tom
2022-08-31  7:49             ` Sebastian Moeller
2022-08-31  9:25               ` Brandon Butterworth
2022-08-31  9:34                 ` David Lang
2022-09-01  9:12                   ` Brandon Butterworth
2022-08-31 14:52   ` Dave Taht
2022-08-31 15:22     ` [Starlink] starlink upload behavior Dave Taht
2022-09-01 19:24       ` Luis A. Cornejo
2022-09-01 19:50         ` Dave Taht
2022-08-31  8:15 [Starlink] Starlink "beam spread" David Fernández
2022-08-31 14:51 David Fernández
2022-08-31 18:09 ` Michael Richardson
2022-08-31 21:46 ` Ulrich Speidel
2022-08-31 23:44   ` Lin Han
2022-09-01 19:26   ` Dave Taht
     [not found] <mailman.800.1661972667.1281.starlink@lists.bufferbloat.net>
2022-08-31 19:51 ` David P. Reed
2022-08-31 20:28   ` David Lang
2022-08-31 21:17     ` David P. Reed
2022-08-31 21:33       ` David Lang
2022-09-01  7:05         ` Mike Puchol
2022-09-01 11:43           ` Ulrich Speidel
2022-09-01  8:09       ` David Lang
2022-09-01 15:19 David Fernández
2022-09-01 16:33 ` Darrell Budic
2022-09-02  9:32   ` David Fernández
2022-09-01 19:56 ` Michael Richardson
2022-09-02 12:27   ` Sebastian Moeller
2022-09-02 18:34     ` Michael Richardson
2022-09-02 20:11       ` Sebastian Moeller

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=7b7bff13-b0ef-41ad-9a40-d12bfe5a0dfe@Spark \
    --to=mike@starlink.sx \
    --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