Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] First tests of the Starlink REV4 (aka gen3)
Date: Thu, 22 Feb 2024 13:18:50 +0100	[thread overview]
Message-ID: <c1d79f9c-75ee-402b-843b-135c0ac5ed90@gmail.com> (raw)
In-Reply-To: <4e7a1b3a-db75-4558-a5aa-42638ffa6962@auckland.ac.nz>



Le 25/01/2024 à 02:54, Ulrich Speidel via Starlink a écrit :
> On 25/01/2024 1:37 am, Alexandre Petrescu via Starlink wrote:
>> Thanks for the tests!
>>
>> The dl/ul speeds 300/15 mbit/s are impressive.
> 
> "Speeds" (observed data rates) in terms of Starlink hardware are 
> actually fairly meaningless as they depend on:
> 
>   * Satellite(s) involved in the data transfer over the duration of the
>     measurement(s).
>   * Load on those satellites, which depends on the number of other
>     current users whose traffic goes via those birds, and what these
>     users are up to. Note this changes between handovers.
>   * RTT to other end of transfer path.
>   * Packet loss (including beyond Starlink's network)
> 
> Unless a Dishy is able to handle communication via multiple satellites 
> in parallel, I would expect the rates to be the same more or less 
> regardless of model used. In fact, I would expect a Dishy model that is 
> able to align itself to do marginally better over time.
> 
>>
>> At video pointer 5:53 the reported Ping ?/dl/ul 88/204/121 ms and Jitter
>> 9.2 ms seem interesting.
>>
>>     ==> I am not sure which of the two (ping or jitter) you name 
>> 'latency'?
> All of them I guess.
>>
>>     ==> I am not sure why the dl (download) ping ms is higher than the ul.
> Because that is where you have the longer queues.
>>
>>     ==> I don't know what is the first ('?') parameter reported as 88ms
>> for Ping?
> 
> I presume unloaded ping RTT. The second is ping RTT during the download 
> test (with inbound queues loaded), the last is ping RTT during the 
> upload test (with outbound queues loaded).
> 
> I'd also note here that these are values obtained from Kyiv, which isn't 
> a Starlink environment that is easy to assess. For one, we don't know 
> whether there are Starlink gateways in Ukraine, or if there are, where 
> they'd be.

One could find 'Kyiv' in the list shown by 
https://geoip.starlinkisp.net/feed.csv

(not sure whether that is a teleport or a point of presence without 
satcom access).

Alex

  We don't know where else there may be gateways - not
> every jurisdiction publishes this - or whether Starlink may even be 
> operating opportunistic fair weather optical gateways which they don't 
> have to disclose to anyone. Plus we don't know what may be carted into 
> the area or away from it via laser links to gateways much further away.
> 
>>
>> I wonder whether the DHCPv6-PD is still supported by REV4 and whether
>> the allocated prefix is still a non-/64 (i.e. a /56 delivered by
>> DHCPv6-PD reported earlier on this email list by Steven on Dec. 12, 2023)?
>>
>> Alex
>>
>> Le 23/01/2024 à 10:07, Oleg Kutkov via Starlink a écrit :
>> > I conducted the initial comparative tests of the new terminal in
>> > Ukraine. I guess it's not a really "legal" because the new terminal is
>> > not certified and not selling outside the US for the moment. But who
>> > cares.
>> >
>> > Here's a video: https://youtu.be/hWPMpJrjd1g 
>> <https://youtu.be/hWPMpJrjd1g>
>> >
>> > I will try to do more technical tests next week. There will be a new
>> > video.
>> >
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink 
>> <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/
> ****************************************************************
> 
> 
> 
> 
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

      reply	other threads:[~2024-02-22 12:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23  9:07 Oleg Kutkov
2024-01-24 12:37 ` Alexandre Petrescu
2024-01-24 22:47   ` Oleg Kutkov
2024-01-24 23:40     ` Jonathan Bennett
2024-01-24 23:50       ` Oleg Kutkov
2024-01-25  1:29         ` David Lang
2024-01-25  1:54   ` Ulrich Speidel
2024-02-22 12:18     ` Alexandre Petrescu [this message]

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=c1d79f9c-75ee-402b-843b-135c0ac5ed90@gmail.com \
    --to=alexandre.petrescu@gmail.com \
    --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