Re: [Bloat] extremely good dslreports result for bufferbloat on free.fr

[Sebastian Moeller <moeller0@gmx.de>]

Hi Jb,


On May 2, 2015, at 15:40 , jb <justin@dslr.net> wrote:

> Each bar is an individual probe they go out once per second, which determines their
> position along the X-Axis, and are tagged by color *when they come back*.

	Thanks, that is exactly the information I was looking for. Given that, I vote for reporting the maximum of the latency under load increases, so take the mean from the pre-download test period and subtract that from each individual download and upload RTT value, select the maximum and report that. Measuring once per second is petty sparse, so no need for any fancy reporting (also good look getting a 98%-percentile for say the 10-11 download RTTs ;) even taking all ~40 RTTs will make 98% hard to reach unless you round… 95% though will work okay-ish).



> For the radar plot, the ones showing latencies to each location, it is nothing to do
> with buffer bloat but there are two green colors super-imposed, the worst and the
> best of several probes per location.

	Ah, I had a hunch that would be that, thanks.

Best Regards
	Sebastian

> 
> On Sat, May 2, 2015 at 9:49 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Jb,
> 
> I wonder the ping RTT plot, does it show all individual RTT-probes, or is it showing an aggregate measure per bar? If aggregate which measure (hopefully the maximum or something close like a high percentile)?
> 
> 
> Best Regards
>         Sebastian
> 
> On May 1, 2015, at 08:31 , jb <justin@dslr.net> wrote:
> 
> > >This got an A+ rating, which I would not have given it, given the
> > enormous load spike.
> >
> > I think there will always be the occasional incorrectly graded test,
> > this one is simply because the median of the downstream latency
> > ignores the spike. If I used average(), then it would not ignore
> > the spike, however one very high outlier could also ruin a good result.
> > After all, pinging anything on the internet can always get the odd
> > bad response now and again.
> >
> > If neither average nor median is any good, then there needs to be
> > a filter function. But what filter? ignoring spikes that are hugely higher
> > than neighbouring ones? that would fail if there was a spike every 3rd
> > sample. Open to ideas..
> >
> > Here is a result from the australian telco free public hotspot:
> >     http://www.dslreports.com/speedtest/399962
> >
> > On the side of the hotspot it says 'send us your thoughts about this
> > free service'. Well my thought is that if one person posted a picture
> > to Instagram, the whole hotspot would be unusable for as long as it
> > took to upload. 6 seconds of buffer in there somewhere.
> >
> > cheers,
> >
> > On Fri, May 1, 2015 at 4:05 PM, Dave Taht <dave.taht@gmail.com> wrote:
> > This got an A+ rating, which I would not have given it, given the
> > enormous load spike.
> >
> > http://www.dslreports.com/speedtest/400387
> >
> > Imagine if your steering wheel behaved like this.
> >
> > On Thu, Apr 30, 2015 at 8:10 PM, jb <justin@dslr.net> wrote:
> > > Already users are like "how can i fix this!".
> >
> > The FAQ can be improved.
> >
> > > I've just replied to one who has lower speeds on the surfboard SB6141 which
> > > is a modem designed for crazy cable speeds. He has an "F" and his downstream
> > > bloat is terrible, and upstream not much better.
> > >
> > > I imagine a LOT of people on slower plans have a "recommended" modem like
> > > this one.
> >
> > I have not found a cable modem with less than 250ms bloat at 50mbit/5.
> > The docsis 3 ones
> > are often in the 800 ms range.
> >
> > >
> > > However most of them will hear that the problems from bloat only happen when
> > > you reach maximum upload or download speed and will think, well, I can live
> > > with that, I never run my connection to capacity and I don't upload to
> > > offsite backups..
> >
> > Latency spikes are annoying no matter how they are inflicted, and happen
> > all the time on nearly any workload. Your test is testing tcp in steady state,
> > most web transactions are bursts of dozens to a hundred flows in slow
> > start.
> >
> > It is the business class customers that feel it most often. I have never
> > visited a business class cable customer that had reasonable amounts of delay
> > and jitter during business hours.
> >
> > After living in  bloat-free universe for quite some time now, annoying
> > issues with things like netflix are decreased, voip and videoconferencing
> > work all the time, same for games...
> >
> > it would be hard to create a metric
> > for user satisfaction, but every before/after comparison someone
> > implementing a solution is quite overjoyed.
> >
> > https://twitter.com/mnot/status/575581792650018816
> >
> > >
> > > On Fri, May 1, 2015 at 10:48 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> > >>
> > >>
> > >> > On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
> > >> > ...
> > >> >> if it did get a rating it would be an "D" or "F"..
> > >> >
> > >> > How about "E" for error? That can be further explained in the text
> > >> > "Sometimes the bloat is so bad that we cannot adaquately test for it -
> > >> > and other times there is something else badly wrong with the link that
> > >> > we cannot identify."
> > >>
> > >> I would stay away from a letter grade for that state, since it could
> > >> appear to be on the continuum of A+, A, B, C, D, E (?) F...
> > >>
> > >> Better to give it a "-" or "?" mark. And if they hover over the "?", let
> > >> the text show: "Sometimes the bloat is so bad that we cannot adaquately test
> > >> for it - and other times there is something else badly wrong with the link
> > >> that we cannot identify."
> > >>
> > >> Rich
> > >
> > >
> >
> >
> >
> > --
> > Dave Täht
> > Open Networking needs **Open Source Hardware**
> >
> > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> 
>