From: jb <justin@dslr.net>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] grading bloat better
Date: Sat, 15 Oct 2016 09:48:15 +1100 [thread overview]
Message-ID: <CAH3Ss96DBtuNCdXN-rBtshtjs1n6BPqnkkG8+uxdkhO0YKFbtw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw65B-v_dA5n2H1ZXya5jZnLNouPAhWh+-FAC+8R_kVbWw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3359 bytes --]
Is this classic buffer bloat on 50 megabit cable modem?
https://www.dslreports.com/forum/r31035315-Weird-speed-test-results-It-falls-off-right-at-the-end
by extending the download duration to 30 seconds, what looks like
a speed "fall-off at the end" reveals two complete stall/recoveries, and
associated
high latency during the download phase.
On Thu, Oct 13, 2016 at 2:22 PM, Dave Taht <dave.taht@gmail.com> wrote:
> Thank you very much for the explanation and the fix. I am confronted
> by the dsltestreports stuff every day on my search for bufferbloat. I
> don't consider it annoying, but as a chance to spot check!
>
> ...
>
> I still might quibble, but a trimmed mean makes more sense than just a
> mean.
>
> Problem I always have is bloat is biased always towards the end of a test.
> Here,
> at 1gbit, it took nearly 20 seconds to start going boom. Maybe we need
> to invent a new distribution (The bloat distribution? The TCP
> distribution)...
>
> You are getting towards a big dataset now. (has it been a year yet?)
> Got anyone lined up for a paper on it? I'd still love it if one day
> someone could take all the data you are filtering out, and plot
> that....
>
> I imagine the user's test result is cached and not subject to these
> modifications?
>
> On Wed, Oct 12, 2016 at 5:57 PM, jb <justin@dslr.net> wrote:
> > It is done
> > under the trimmed mean method, that would be a "C" grade result.
> >
> >
> >
> > On Thu, Oct 13, 2016 at 11:46 AM, jb <justin@dslr.net> wrote:
> >>
> >> Actually I think the concept I need is the trimmed mean.
> >> throwing away the highest couple of values (lowest couple are not to be
> >> thrown away because they can't be errant).
> >> It isn't perfect but it would help.
> >>
> >> On Thu, Oct 13, 2016 at 11:39 AM, jb <justin@dslr.net> wrote:
> >>>
> >>> A while ago I changed from mean to median with the reasoning being that
> >>> one spike to a crazy level was not representative of bloat but instead
> >>> representative of a network stall or other anomaly. Graphs that were
> nearly
> >>> all good samples with one outlier were being unfairly graded poorly.
> >>>
> >>> But this example has the opposite issue - the median of this set of
> >>> samples is the first half where everything is ok. Hence the good score.
> >>> Using a mean would be correct for this sample.
> >>> What should happen is to throw away a couple (max) outliers first, then
> >>> do a mean to avoid punishing the results that come in as good but
> include
> >>> one errant measurement.
> >>>
> >>> thanks
> >>> -Justin
> >>>
> >>> On Wed, Oct 12, 2016 at 11:16 PM, Dave Taht <dave.taht@gmail.com>
> wrote:
> >>>>
> >>>> This has major bloat happening at the end of the upload test. Which
> >>>> worries me - here, at a gbit.
> >>>>
> >>>> http://www.dslreports.com/speedtest/5284047
> >>>>
> >>>> --
> >>>> Dave Täht
> >>>> Let's go make home routers and wifi faster! With better software!
> >>>> http://blog.cerowrt.org
> >>>> _______________________________________________
> >>>> Bloat mailing list
> >>>> Bloat@lists.bufferbloat.net
> >>>> https://lists.bufferbloat.net/listinfo/bloat
> >>>
> >>>
> >>
> >
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
>
[-- Attachment #2: Type: text/html, Size: 5040 bytes --]
next prev parent reply other threads:[~2016-10-14 22:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 12:16 Dave Taht
2016-10-13 0:39 ` jb
2016-10-13 0:46 ` jb
2016-10-13 0:57 ` jb
2016-10-13 3:22 ` Dave Taht
2016-10-13 4:37 ` Jonathan Morton
2016-10-14 22:48 ` jb [this message]
2016-10-15 4:39 ` Dave Taht
2016-10-15 5:35 ` Jonathan Morton
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=CAH3Ss96DBtuNCdXN-rBtshtjs1n6BPqnkkG8+uxdkhO0YKFbtw@mail.gmail.com \
--to=justin@dslr.net \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.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