From: J Pan <Pan@uvic.ca>
To: "Livingood, Jason" <jason_livingood@comcast.com>
Cc: Dave Taht <dave.taht@gmail.com>,
Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: Re: [Starlink] musk: 28ms median latency on starlink
Date: Tue, 4 Jun 2024 11:34:11 -0700 [thread overview]
Message-ID: <CAHn=e4jAGT5B4jdsRxPFfNL=3vW4k8pB81LcTs=R533DUiDBFg@mail.gmail.com> (raw)
In-Reply-To: <BEA4C698-10C8-4A73-80B8-631C75DC2C3E@comcast.com>
it's the user dish (ut) to pop (or ip gateway more precisely, not the
ground station, collocated with the user's home pop) latency. thanks
for the ripe atlas probes---we are hosting and using them too---the
downside of ripe atlas is that it's mostly user hosted (so not always
online) and the space and time granularity of the measurements that
can be done for research
--
J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM), Pan@UVic.CA, Web.UVic.CA/~pan
On Tue, Jun 4, 2024 at 9:33 AM Livingood, Jason via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> First question is what was the test destination? From the CPE to a ground station or to something at a peering point or on the internet? I would assume either to ground station or 1 hop beyond (peering point)… That way we can do apples-to-apples comparisons, so to speak.
>
>
>
> In any case, there is a lot of good 3rd party data out there for this. First is RIPE Atlas. I helped get a lot of probes deployed in the US and there are now 78 probes connected globally (roughly 30 would be sufficient to call it statistically significant): https://atlas.ripe.net/probes/public?sort=-id&toggle=all&page_size=100&search=AS14593&page=1&status=1. So if you know how to pull data from Atlas, it is there for you to analyze… (see https://atlas.ripe.net/docs/apis/rest-api-manual/ and https://atlas.ripe.net/docs/tools-and-code/latencymon.html
>
>
>
> There is also this recent report that used a hardware probe connected over ethernet: https://www.netforecast.com/wp-content/uploads/FixedWireless_LEO_CableComparisonReport_NFR5148-1.pdf
>
>
>
> Another approach similar to accessing RIPE Atlas data would be to get the Cloudflare AIM data from M-Lab – see https://www.measurementlab.net/blog/cloudflare-aimscoredata-announcement/. There was also a recent 3rd party report on that (see Figure 1): https://www.netforecast.com/wp-content/uploads/NFR5150_NetForecast-ISP-Performance-Report-2024.pdf.
>
>
>
> Jason
>
>
>
>
>
> From: Starlink <starlink-bounces@lists.bufferbloat.net> on behalf of Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: Dave Taht <dave.taht@gmail.com>
> Date: Sunday, June 2, 2024 at 13:13
> To: Dave Taht via Starlink <starlink@lists.bufferbloat.net>
> Subject: [Starlink] musk: 28ms median latency on starlink
>
>
>
> Via elon musk:
>
>
>
> Starlink just achieved a new internal median latency record of 28ms yesterday! Great work by the engineering and operations teams.
>
>
>
> - https://twitter.com/elonmusk/status/1797282250574184587
>
>
>
> I of course, am very interested in y'all´s external measurements of how well starlink is doing. For me, it is fantastic - 30Mbit uploads nowadays, 0
>
> latency on the upload (how?) https://www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe
>
>
>
> I also keep hoping that the rest of the ISP industry is now paying attention and deploying stuff like fq_codel and cake and libreqos, but, ah well - I will settle for starlink blowing past a lot of dsl and cable and finding ways to get their density up.
>
>
>
> Anyone going to the Starship launch on the 6th?
>
>
>
>
>
>
> --
>
> https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s Waves Podcast
>
> Dave Täht CSO, LibreQos
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
next prev parent reply other threads:[~2024-06-04 18:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-02 17:13 Dave Taht
2024-06-02 18:17 ` Sauli Kiviranta
2024-06-02 18:23 ` Oleg Kutkov
2024-06-03 10:40 ` Ulrich Speidel
2024-06-03 16:43 ` David Lang
2024-06-03 17:41 ` Mike Puchol
2024-06-03 21:59 ` Ulrich Speidel
2024-06-04 0:08 ` J Pan
2024-06-04 14:53 ` Alexandre Petrescu
2024-06-04 18:24 ` David Lang
2024-06-04 16:33 ` Livingood, Jason
2024-06-04 18:34 ` J Pan [this message]
2024-06-05 11:08 ` Alexandre Petrescu
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=e4jAGT5B4jdsRxPFfNL=3vW4k8pB81LcTs=R533DUiDBFg@mail.gmail.com' \
--to=pan@uvic.ca \
--cc=dave.taht@gmail.com \
--cc=jason_livingood@comcast.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