From: Ulrich Speidel <u.speidel@auckland.ac.nz>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] A year of Starlink latency and loss metrics
Date: Fri, 14 Jun 2024 15:17:24 +1200 [thread overview]
Message-ID: <c560cf25-2359-4c61-9840-7475fb31fe3f@auckland.ac.nz> (raw)
In-Reply-To: <CALWT4TK5uiryD9JG4bLJsZHub_+-eo6S8gb3oQbMZU0ffKOu_Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
On 12/06/2024 4:32 pm, Tristan Horn via Starlink wrote:
> Not my metrics, but spotted this on Reddit and I'm always a sucker for
> Grafana graphs:
>
> https://www.reddit.com/r/Starlink/comments/1dd4wjs/i_collected_metrics_on_my_starlink_for_nearly_a/
>
> I probably have little relevant to add (I returned my Starlink
> terminal in 2023), but the thread inspired me to get some stats going
> again myself (using the same ping_exporter
> <https://github.com/czerwonk/ping_exporter>). I used to even collect
> minutely traceroutes and single-stream TCP throughput ... I've gotten
> soft, I guess.
The first thing I noticed looking at that graph was that the average
latency has been declining over time, with only two discernible "steps".
That tells me two things:
1. Steps are generally the consequence of an event. For Starlink, this
could be introduction of (different) AQM resulting in lower queue
sojourn times. Or it could be different routing / scheduling that
results in lower physical path latencies as a result of better paths
being chosen.
2. Gradual decline over time is likely to be the result of a
longer-term change process. For Starlink, there are two longer term
trends that come to mind: customer numbers and satellite capacity.
I'd be inclined to suspect the latter is to "blame" for the gradual
decline component here. If your Dishy sees more satellites now than
a year ago, there's a higher probability that it'll get to talk to a
satellite that's closer to both you and the respective gateway.
You'd also expect stdev to decline in the case, which again is what
we see here.
Minimal latency will happen pretty much when the "Starlinks align" to
give your ping empty queues with a satellite in near-optimal position to
your gateway. Again not surprising that we don't see much of a drop here.
--
****************************************************************
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: 3157 bytes --]
next prev parent reply other threads:[~2024-06-14 3:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 4:32 Tristan Horn
2024-06-14 3:17 ` Ulrich Speidel [this message]
2024-07-08 4:54 ` J Pan
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=c560cf25-2359-4c61-9840-7475fb31fe3f@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