Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink in Northern Europe: A New Look at Stationary and In-motion Performance
Date: Fri, 28 Feb 2025 10:02:15 +1300	[thread overview]
Message-ID: <e2426f49-d69f-479a-ad62-12c67f7f3e97@auckland.ac.nz> (raw)
In-Reply-To: <CAFvDQ9pPTd5-Pw2sn8LasV6j0wn4gP9r9O=4fRh=7wifnijQ+A@mail.gmail.com>

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

I had a quick look.

The most important bit of information I was looking for is on page 7, 
and it's not explicitly mentioned despite its importance - rather it's 
delivered on the side of the figures: the latitude of the measurements. 
Ballpark 65 deg north. That puts the measurements beyond the range of 
the bulk of the Starlink shells at 43, 53, and 53.2 degrees inclination, 
leaving only the 70 and 97.6 deg inclination shells within view.

Why does this matter? Two reasons:

 1. A location at 65 deg north sees on average around 8 qualifying
    satellites at any time - those are satellites that are at least 25
    deg above the horizon (so their beams don't get into terrestrial
    microwave link receivers). That compares to over 40 qualifying
    satellites should you find yourself luck to live between 40 and 45
    deg north, and over 20 at the Equator (even keeping GSO protection
    into account).
 2. The qualifying satellites you see north of about 60 deg are still
     >90% version 1.5's. They have lasers for backhaul but a
    comparatively small number of Ku band beams for downlink to Dishy.
    South of 40 degrees, almost half the qualifying satellites you're
    going to encounter are from the version 2 series, which have a lot
    more beams. These beams are also higher capacity ones.

Why does the number of qualifying satellites and beams matter? 
Basically, if you add up all beams on all satellites within view, you 
get the pool of beams that Starlink can pick from to serve your Dishy. 
More beams in total = more options = bigger cake = bigger slice of 
capacity for your Dishy.

Now how big a slice of the cake you can get depends not only on the 
satellite mix in view, but also on how many other user terminals in your 
immediate (cell) and wider (nearby cells) in your neighbourhood want to 
access that capacity cake. This depends a lot on population density and 
on what the competing terrestrial connectivity options are. In a place 
with low population density, fibre to almost everywhere and a good 4G 
and 5G coverage, all at good prices, there won't be a lot of competing 
users for the cake. The Oulu area in Finland, where they took the 
measurements, appears to be in that category, mostly. The paper doesn't 
discuss these determinants of performance, however.

On 28/02/2025 4:04 am, Hesham ElBakoury via Starlink wrote:
> Hi Craig,
> No it is not my paper.
> It has interesting results that I would like others to see and provide 
> feedback on.
>
> Hesham
>
> On Thu, Feb 27, 2025, 6:36 AM Craig Polk <c.polk@comsoc.org> wrote:
>
>     Hesham,
>
>     Is this your paper? Are you submitting it for the WG to review as
>     a possible INGR Topic article?
>
>     Best regards,
>     Craig
>
>     ----
>     Craig Polk, MSEE, MBA
>     Program Manager
>     Future Networks Tech Community | futurenetworks.ieee.org
>     <http://futurenetworks.ieee.org>
>     3 Park Avenue, 17th Floor, New York, NY 10016
>     <https://www.google.com/maps/search/3+Park+Avenue,+17th+Floor,+New+York,+NY+10016%C2%A0++Office:+%2B1?entry=gmail&source=g>
>     Office: +1
>     <https://www.google.com/maps/search/3+Park+Avenue,+17th+Floor,+New+York,+NY+10016%C2%A0++Office:+%2B1?entry=gmail&source=g>
>     212-705-8926 | Mobile: +1 908-255-6568
>     Email: c.polk@comsoc.org
>     Future Networks World Forum | https://fnwf.ieee.org/
>     Connecting the Unconnected | https://ctu.ieee.org/
>
>     On Thu, Feb 27, 2025, 12:01 AM Hesham ElBakoury
>     <helbakoury@gmail.com> wrote:
>
>         This paper [1] This paper evaluates the Flat High Performance
>         (FHP) terminal's performance in Finland, Northern Europe.
>
>         *_Abstract_*
>         "Starlink has introduced the Flat High Performance (FHP)
>         terminal, specifically designed to support the vehicles and
>         the vessels in motion as well as the high-demand stationary
>         users. The research on FHP terminal throughput analysis
>         remains limited, only a few existing studies evaluate FHP,
>         focusing on the limited parameters and scenarios. This paper
>         evaluates the FHP terminal's performance in Finland, Northern
>         Europe. We examine round-trip time (RTT), uplink, and downlink
>         throughput for both stationary and in-motion use. We measure
>         network efficiency across six geographically diverse servers
>         and get insights of network routing strategies. Our results
>         show that Starlink provides high-speed, low-RTT connectivity,
>         however, the throughput experiences fluctuations with slight
>         degradation when in motion. Additionally, we compare Starlink
>         and terrestrial network RTT and possible routing paths."
>
>         Hesham
>         [1] https://arxiv.org/abs/2502.15552
>         ------------------------------------------------------------------------
>
>         To unsubscribe from the 5GRM-SATELLITE list, click the
>         following link:
>         https://listserv.ieee.org/cgi-bin/wa?SUBED1=5GRM-SATELLITE&A=1
>         <https://listserv.ieee.org/cgi-bin/wa?SUBED1=5GRM-SATELLITE&A=1>
>
>
> _______________________________________________
> 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: 9312 bytes --]

  reply	other threads:[~2025-02-27 21:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-27  5:00 Hesham ElBakoury
2025-02-27 14:18 ` Sascha Meinrath
2025-02-27 14:36 ` Craig Polk
2025-02-27 15:04   ` Hesham ElBakoury
2025-02-27 21:02     ` Ulrich Speidel [this message]
2025-02-28  3:40       ` Daniel AJ Sokolov
2025-02-28  4:22         ` Ulrich Speidel
2025-02-28  4:57           ` Daniel AJ Sokolov

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=e2426f49-d69f-479a-ad62-12c67f7f3e97@auckland.ac.nz \
    --to=u.speidel@auckland.ac.nz \
    --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