[Bloat] Bufferbloat test measurements

[jb]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20160828/d21f21bf/attachment-0002.html>