[LibreQoS] [Starlink] NZ latest latency report

dan dandenson at gmail.com
Thu Aug 17 11:29:28 EDT 2023


I can imagine the end-to-end latency is something they might not want to
talk about.    I'm saying this in the context of the english speaking world
and transit times from AU and NZ to US, CA, UK.

Keep in mind that one-way, it's 35ms from Auckland to Los Angeles for those
photons in a vacuum, slightly more in a strand of glass.

Cross-planet content really needs to be latency insensitive until we get
some sort of FTL data streams lol.

But if you are stuck with 35ms across the ocean to the nearest english
speaking country, it's even more important to have the last mile be as low
latency as possible.

The 'content' can just be moved nearer, ie hulu and netflix and the like,
but realtime coms with American has an extra 35ms and London 65ms one-way
cost so you really can't afford to have 50ms to the end user on either side.



On Wed, Jul 5, 2023 at 6:17 PM Dick Roy via LibreQoS <
libreqos at lists.bufferbloat.net> wrote:

> I’m not the expert in the room, however I find the report lacking in one
> very important area.  All these results on latencies, speed, etc., are
> categorized based on users “first mile access” technology, leqding the
> reader to believe the sole source of these numbrs is the “first mile” which
> of course it is not.  They do not address the as important issues of the
> rest of what’s between “end-2-end”.  Take a look at the gaming latency
> results, and you see games hosted in America have very high latencies for
> users in New Zealand … duhhhhhh!  This can’t be news.
>
>
>
> While not trivial by any means, what could/should be done to make these
> data more useful for consumers is to figure out the effect of everything
> past the “first mile/first hop” and break it out separately.  That way, a
> (moderately intelligent) user could make a reasonably informed cost-benefit
> analysis on which combination of first mile technology and back-end service
> provider to choose, assuming there were service providers that offered a
> choice of “first-mile’ access, or backhaul providers that served a variety
> of “first mile” providers.  Guess we’re a few years away from that J
>
>
>
> RR
>
>
>
> -----Original Message-----
> From: Starlink [mailto:starlink-bounces at lists.bufferbloat.net] On Behalf
> Of Dave Taht via Starlink
> Sent: Wednesday, July 5, 2023 6:08 AM
> To: libreqos; Rpm; Dave Taht via Starlink
> Cc: Sam Crawford
> Subject: [Starlink] NZ latest latency report
>
>
>
> I do wish that it broke it out by provider, and recommended somehow to
>
> those suffering still, install a better device... VDSL can be made
>
> vastly more tolerable. Otherwise pretty good, and brings in
>
> starlink...
>
>
>
>
> https://comcom.govt.nz/__data/assets/pdf_file/0016/320326/MBNZ-Autumn-Report-28-June-2023.pdf
>
>
>
> To pick on samknows a little bit, I think the test does not run long
>
> enough, and should be pulling from higher than what appears to be the
>
> 75th percentile.
>
>
>
>
>
>
>
> --
>
> Podcast:
> https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
>
> Dave Täht CSO, LibreQos
>
> _______________________________________________
>
> Starlink mailing list
>
> Starlink at lists.bufferbloat.net
>
> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/libreqos/attachments/20230817/912afc1f/attachment-0001.html>


More information about the LibreQoS mailing list