Many ISPs need the kinds of quality shaping cake can do
 help / color / mirror / Atom feed
From: dan <dandenson@gmail.com>
To: dickroy@alum.mit.edu
Cc: Dave Taht <dave.taht@gmail.com>,
	libreqos <libreqos@lists.bufferbloat.net>,
	Rpm <rpm@lists.bufferbloat.net>, Sam Crawford <sam@samknows.com>
Subject: Re: [LibreQoS] [Starlink] NZ latest latency report
Date: Thu, 17 Aug 2023 09:29:28 -0600	[thread overview]
Message-ID: <CAA_JP8U8beDxt5erf9q5-PVxOsb7V22B8C6P5nTPd05X7tKZLQ@mail.gmail.com> (raw)
In-Reply-To: <6C0AE2724B354B1E87B55C42C159CC27@SRA6>

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

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@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@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@lists.bufferbloat.net
>
> https://lists.bufferbloat.net/listinfo/starlink
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

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

      reply	other threads:[~2023-08-17 15:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-05 13:08 [LibreQoS] " Dave Taht
2023-07-05 21:17 ` [LibreQoS] [Starlink] " Ulrich Speidel
2023-07-06  0:17 ` Dick Roy
2023-08-17 15:29   ` dan [this message]

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/libreqos.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA_JP8U8beDxt5erf9q5-PVxOsb7V22B8C6P5nTPd05X7tKZLQ@mail.gmail.com \
    --to=dandenson@gmail.com \
    --cc=dave.taht@gmail.com \
    --cc=dickroy@alum.mit.edu \
    --cc=libreqos@lists.bufferbloat.net \
    --cc=rpm@lists.bufferbloat.net \
    --cc=sam@samknows.com \
    /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