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 wrote: > Hi Brennan, > > really cool stuff! > > > On May 13, 2022, at 01:35, Brennen Smith 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 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 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 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 >