[Starlink] A year of Starlink latency and loss metrics

[Starlink] A year of Starlink latency and loss metrics

[Tristan Horn]

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

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.

Tris

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

Re: [Starlink] A year of Starlink latency and loss metrics

[Ulrich Speidel]

[-- 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 --]

Re: [Starlink] A year of Starlink latency and loss metrics

[J Pan]

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