Re: [Bloat] grading bloat better

[Dave Taht <dave.taht@gmail.com>]

On Fri, Oct 14, 2016 at 3:48 PM, jb <justin@dslr.net> wrote:
> Is this classic buffer bloat on 50 megabit cable modem?

Looks like it.

> 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
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org