From: J Pan <Pan@uvic.ca>
To: Ulrich Speidel <u.speidel@auckland.ac.nz>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] A year of Starlink latency and loss metrics
Date: Sun, 7 Jul 2024 21:54:12 -0700 [thread overview]
Message-ID: <CAHn=e4hWmZ7XATmbNLahuvGO252aN7vNDA0_Y0YFZV-2X3wfnA@mail.gmail.com> (raw)
In-Reply-To: <c560cf25-2359-4c61-9840-7475fb31fe3f@auckland.ac.nz>
starlink has made great improvements for bent pipes (both the user
dish and landing ground station are seen by the same satellite) but
they still need to improve for inter-satellite links, which is an even
harder problem. how's the starlink performance in kiribati using isl
links?
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
On Thu, Jun 13, 2024 at 8:17 PM Ulrich Speidel via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> 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). 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:
>
> 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.
> 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/
> ****************************************************************
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
prev parent reply other threads:[~2024-07-08 4:54 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
2024-07-08 4:54 ` J Pan [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='CAHn=e4hWmZ7XATmbNLahuvGO252aN7vNDA0_Y0YFZV-2X3wfnA@mail.gmail.com' \
--to=pan@uvic.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