On Fri, Oct 14, 2016 at 3:48 PM, jb <jus...@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.t...@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 <jus...@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 <jus...@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 <jus...@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.t...@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 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat