Re: [Starlink] ookla's latest speedtest app does latency under load

["Luis A. Cornejo" <luis.a.cornejo@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4851 bytes --]

Square dishy. North of Houston, speeds have been subpar recently compared
to initial setup in late March (100+/10+). My cell is probably saturated
considering my latitude, bird density, and possibly base station.

https://www.speedtest.net/my-result/i/5118600624



On Fri, May 13, 2022 at 2:09 PM Möller, Sebastian <SMoeller@dpz.eu> wrote:

> Hi Brennan,
>
> really cool stuff!
>
>
> On May 13, 2022, at 01:35, Brennen Smith <brennen@ookla.com> wrote:
>
> Hey all,
>
> Here's some details about the final figures:
>
> 1. Loaded latency is simply an extension of the latency stage - same
> methodology and medium
>
>
> Where could I find a technical description of that method?
>
> 2. We use a "warmed up" TCP connection for latency
>
>
> Is that one of the load bearing flows or a non load bearing parallel flow
> that has successfully finished the TCP handshake?
>
> 3. We use the interquartile mean for the "displayed value"
>
>
> I wonder whether reporting something like a 95 or 99% quantiles (so either
> 1& and 99%, or 5% and 95%) in addition to min and max and interquartile
> mean would be possible? And since you use the 25 and 75% values already,
> maybe these as well?
>
> Awesome seeing those numbers in the wild and looking forward to bringing
> more awareness to this issue.
>
>
> For sure, so far many discussions about debugging/reducing bufferbloat
> started with people wanting to use the ubiquitious speedtest.nat nodes
> (where finding a close by one typically is easy/possible); and now this
> will actually work (assuming they use Android or iOS clients).
>
> Question: will the apps for the other OSs as well as the CLI and the web
> version also be changed to include these numbers in the foreseeable future?
>
>
> Kind Regards
> Sebastian
>
>
>
> Cheers,
>
> Brennen Smith
>
> VP Technology
>
> (206) 739-0807 | brennen@ookla.com
> linkedin.com/in/brennensmith
>
>
> On Thu, May 12, 2022 at 4:18 PM Dave Taht <dave.taht@gmail.com> wrote:
> Yea. peak 2500ms latency on download, 600ms on upload, that's about right.
> :/ The upload figure appears to be a bit lower (better) than what I
> measured 1 year ago, here (for the 30 or so new subscribers on this list,
> this was why I started it):
> https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit
>
> I don't know if ookla are throwing out arp related stuff, or using the
> 99th percentile to calculate the final figure. I hope to learn more about
> their calculations in the coming weeks.
>
> I do keep hoping we can get more updated flent data over longer intervals
> than 20s. With starlink changing their allocation scheme every 15s, what
> number do you pick?
>
> And like I said, some packet caps of this app would be good, too.
>
>
>
> On Thu, May 12, 2022 at 4:07 PM Nathan Owens <nathan@nathan.io> wrote:
> Here's a test I did today:
> https://www.speedtest.net/my-result/i/5112435305
>
>
>
>
> On Thu, May 12, 2022 at 4:04 PM Dave Taht <dave.taht@gmail.com> wrote:
> Ookla has just put out an ios and android app that also continuously
> measures latency under load.
>
> I'm interested in calibrating the results of that vs a vs flent
> benchmarks verses starlink. Can someone here give this a shot? More
> details here:
>
>
> https://www.ookla.com/articles/introducing-loaded-latency
>
> IDEALLY, this would be over wifi -> starlink , with a packet capture
> in the middle. But I'd settle for a few test results from starlink
> folk of this new app, first.
>
> --
> FQ World Domination pending:
> https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> --
> FQ World Domination pending:
> https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC
>
>
> This email, its contents and attachments contain information from Ziff
> Davis, Inc. and/or its affiliates which may be privileged, confidential or
> otherwise protected from disclosure. The information is intended to be for
> the addressee(s) only. If you are not an addressee, any disclosure, copy,
> distribution or use of the contents of this message is prohibited. If you
> have received this email in error, please notify the sender by reply email
> and delete the original message and any copies.
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #1.2: Type: text/html, Size: 7858 bytes --]

[-- Attachment #2: IMG_3074.jpeg --]
[-- Type: image/jpeg, Size: 82378 bytes --]

[-- Attachment #3: image_123986672.JPG --]
[-- Type: image/png, Size: 188464 bytes --]