From: jb <justin@dslr.net>
To: Kathleen Nichols <nichols@pollere.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Bufferbloat test measurements
Date: Sun, 28 Aug 2016 12:23:57 +1000 [thread overview]
Message-ID: <CAH3Ss94fisQWf-hb2hT6EVm1AaXj5EgnY+f_P6zosga=kG6cxA@mail.gmail.com> (raw)
In-Reply-To: <5c615f4b-6162-915d-897c-871c3e843ed2@pollere.com>
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
The grade for one speed test represents something that the user may already
recognise as being a problem, and may do something about. The aggregation
of grades can highlight ISPs that are afflicted with end-user hardware that
could be improved, I suppose. Is it even possible to detect ISPs afflicted
with buffer related latency issues within their infrastructure using an
environment where people running tests of any kind have huge CPE or Wifi
buffers already?
Yep the ideal situation is to have people use their entire link bandwidth
and yet any additional stream should be almost as low in latency as idle
latency is. That is what a grade of A+ would be highlighting, and many
people have got there after seeing a poor grade and doing something about
it.
Regarding capping of speeds I'm just pointing out that a "cheap fix" for
some people has been to throttle especially the upstream bandwidth
(somehow) just below the upstream rate discovered to be the max - which
reduces the opportunity to fill a large upload buffer in the modem. It is a
kludge but without replacing equipment or re-flashing firmware, sometimes
is the only option open to them.
On Sun, Aug 28, 2016 at 10:14 AM, Kathleen Nichols <nichols@pollere.com>
wrote:
>
> Hi, Justin,
> Thanks for the explanations. So the grade is for the user not the ISP?
>
> I just have to point out that the below jumped out at me a bit. A user
> can fully use the link bandwidth capacity and not have an unacceptable
> latency. After all, that's the goal of AQM. But, yes, there are those
> pesky lurking buffers in the path which the user might unhappily
> use to their full capacity and then latency can be unacceptable.
>
> Kathie
>
> On 8/27/16 4:39 PM, jb wrote:
> >
> > Generally if a user does not use their connection to full capacity,
> latency
> > is acceptable (but obviously the buffers are still there, lurking).
> > Bursts and
> > so on can discover them again but the effects are transient.
>
[-- Attachment #2: Type: text/html, Size: 2455 bytes --]
prev parent reply other threads:[~2016-08-28 2:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-27 11:46 [Bloat] Bufferbloat test measurements (was: Open Source Speed Test) Rich Brown
2016-08-27 15:19 ` Kathleen Nichols
2016-08-27 16:03 ` [Bloat] Bufferbloat test measurements Alan Jenkins
2016-08-27 17:37 ` Kathleen Nichols
2016-08-27 19:18 ` Alan Jenkins
2016-08-27 19:39 ` Alan Jenkins
2016-08-27 23:39 ` jb
2016-08-28 0:14 ` Kathleen Nichols
2016-08-28 2:23 ` jb [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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH3Ss94fisQWf-hb2hT6EVm1AaXj5EgnY+f_P6zosga=kG6cxA@mail.gmail.com' \
--to=justin@dslr.net \
--cc=bloat@lists.bufferbloat.net \
--cc=nichols@pollere.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