[Bloat] dslreports mockup

[Bloat] dslreports mockup

[Dave Taht]

I wanted to be able to have separated charts for up and down on
different scales, so I took apart what exists today in gimp and got
this:

http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png

I guess it is partially because I am getting a C on the download at
this speed, and no A+ on the upload, and I would at least like to get
a gold star from teacher for effort. :/

I dunno how to fix the download short of getting rid of several
seconds of inherent buffering in their CMTS. There must be a simple
way to do that??

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] dslreports mockup

[Rich Brown]

That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different. 

The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home.  But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem. 

* If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion

* If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts.

* On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds...

Other thoughts?

Rich

On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I wanted to be able to have separated charts for up and down on
> different scales, so I took apart what exists today in gimp and got
> this:
> 
> http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
> 
> I guess it is partially because I am getting a C on the download at
> this speed, and no A+ on the upload, and I would at least like to get
> a gold star from teacher for effort. :/
> 
> I dunno how to fix the download short of getting rid of several
> seconds of inherent buffering in their CMTS. There must be a simple
> way to do that??
> 
> -- 
> 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

Re: [Bloat] dslreports mockup

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

Providing separate grades for upload and download does not make sense to
me, as interference with acks in the other direction badly hurts that
traffic. Uploads and downloads are *not* independent variables.

KISS: one grade....
                  - Jim


On Thu, May 21, 2015 at 9:45 AM, Rich Brown <richb.hanover@gmail.com> wrote:

> That is interesting. I'm trying to think how the latency charts could be
> misconstrued, since a Y-axis on the right isn't the norm - I don't think
> it's hard to understand, but just different.
>
> The display as-is clearly shows that the download is badly bloated, but
> the upload is fine. That's the important message for most people at home.
> But as a researcher, you want to understand the details of the upload. So
> having different scales would help you see better into the problem.
>
> * If the download and upload values are substantially similar, the left
> and right Y-axis scales should be the same, so there wouldn't be confusion
>
> * If the values are substantially different (as in this screen shot), the
> pink and yellow backgrounds (on the left) and the lack of them on the right
> would provide a solid cue that there is something different going on
> between the two charts.
>
> * On the other hand, the report already shows different Y-axis values for
> the down/upload speeds, so the latency charts could mimic the speeds...
>
> Other thoughts?
>
> Rich
>
> On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
>
> > I wanted to be able to have separated charts for up and down on
> > different scales, so I took apart what exists today in gimp and got
> > this:
> >
> > http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
> >
> > I guess it is partially because I am getting a C on the download at
> > this speed, and no A+ on the upload, and I would at least like to get
> > a gold star from teacher for effort. :/
> >
> > I dunno how to fix the download short of getting rid of several
> > seconds of inherent buffering in their CMTS. There must be a simple
> > way to do that??
> >
> > --
> > 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
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 3903 bytes --]

Re: [Bloat] dslreports mockup

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]

Ahah! I wasn't clear. I do want One Grade to Rule Them All...

But I was only talking about different Y-axis values on the latency charts, so that a bad latency in one direction doesn't hide the details of the transfer in the other.

Rich

On May 21, 2015, at 10:13 AM, Jim Gettys <jg@freedesktop.org> wrote:

> Providing separate grades for upload and download does not make sense to me, as interference with acks in the other direction badly hurts that traffic. Uploads and downloads are *not* independent variables.
> 
> KISS: one grade....
>                   - Jim
> 
> 
> On Thu, May 21, 2015 at 9:45 AM, Rich Brown <richb.hanover@gmail.com> wrote:
> That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different.
> 
> The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home.  But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem.
> 
> * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion
> 
> * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts.
> 
> * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds...
> 
> Other thoughts?
> 
> Rich
> 
> On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> > I wanted to be able to have separated charts for up and down on
> > different scales, so I took apart what exists today in gimp and got
> > this:
> >
> > http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
> >
> > I guess it is partially because I am getting a C on the download at
> > this speed, and no A+ on the upload, and I would at least like to get
> > a gold star from teacher for effort. :/
> >
> > I dunno how to fix the download short of getting rid of several
> > seconds of inherent buffering in their CMTS. There must be a simple
> > way to do that??
> >
> > --
> > 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
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 


[-- Attachment #2: Type: text/html, Size: 4651 bytes --]

Re: [Bloat] dslreports mockup

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 3154 bytes --]

On Thu, May 21, 2015 at 10:24 AM, Rich Brown <richb.hanover@gmail.com>
wrote:

> Ahah! I wasn't clear. I do want One Grade to Rule Them All...
>
> But I was only talking about different Y-axis values on the latency
> charts, so that a bad latency in one direction doesn't hide the details of
> the transfer in the other.
>
>
​Ah, yes.  That makes sense.
                     - Jim
​


> Rich
>
> On May 21, 2015, at 10:13 AM, Jim Gettys <jg@freedesktop.org> wrote:
>
> Providing separate grades for upload and download does not make sense to
> me, as interference with acks in the other direction badly hurts that
> traffic. Uploads and downloads are *not* independent variables.
>
> KISS: one grade....
>                   - Jim
>
>
> On Thu, May 21, 2015 at 9:45 AM, Rich Brown <richb.hanover@gmail.com>
> wrote:
>
>> That is interesting. I'm trying to think how the latency charts could be
>> misconstrued, since a Y-axis on the right isn't the norm - I don't think
>> it's hard to understand, but just different.
>>
>> The display as-is clearly shows that the download is badly bloated, but
>> the upload is fine. That's the important message for most people at home.
>> But as a researcher, you want to understand the details of the upload. So
>> having different scales would help you see better into the problem.
>>
>> * If the download and upload values are substantially similar, the left
>> and right Y-axis scales should be the same, so there wouldn't be confusion
>>
>> * If the values are substantially different (as in this screen shot), the
>> pink and yellow backgrounds (on the left) and the lack of them on the right
>> would provide a solid cue that there is something different going on
>> between the two charts.
>>
>> * On the other hand, the report already shows different Y-axis values for
>> the down/upload speeds, so the latency charts could mimic the speeds...
>>
>> Other thoughts?
>>
>> Rich
>>
>> On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> > I wanted to be able to have separated charts for up and down on
>> > different scales, so I took apart what exists today in gimp and got
>> > this:
>> >
>> > http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
>> >
>> > I guess it is partially because I am getting a C on the download at
>> > this speed, and no A+ on the upload, and I would at least like to get
>> > a gold star from teacher for effort. :/
>> >
>> > I dunno how to fix the download short of getting rid of several
>> > seconds of inherent buffering in their CMTS. There must be a simple
>> > way to do that??
>> >
>> > --
>> > 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
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5447 bytes --]

Re: [Bloat] dslreports mockup

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 3786 bytes --]



> On 21 May 2015, at 15:23, Jim Gettys <jg@freedesktop.org> wrote:
> 
> Providing separate grades for upload and download does not make sense to me, as interference with acks in the other direction badly hurts that traffic. Uploads and downloads are *not* independent variables.
> 
> KISS: one grade....
>                   - Jim

As a dumb user I agree with the one overall grade result. As a slightly less dumb user seeing up & down graphs is useful for tuning bandwidth limits, or I found it so at least. It's suddenly struck me as odd that a test section & graph for simultaneous up & down streams isn't included, presumably it would also be the basis for the one grade overall badge result. I guess that's feedback to dslreports if they're not already listening here.

Agree with Rich's comments re: background colours following scaling as a further pointer to bad/better/good on up/down latency differences.

Kevin

PS: As an aside I don't know if my comments/thoughts are helpful on this list or not.  I know there are a lot of extremely experienced & clever people here who've been battling this problem for a long time and I fear 'stupid' questions will just try people's patience.  If my dumb user observations aren't helpful please tell me to shut up!
> 
> 
>> On Thu, May 21, 2015 at 9:45 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>> That is interesting. I'm trying to think how the latency charts could be misconstrued, since a Y-axis on the right isn't the norm - I don't think it's hard to understand, but just different.
>> 
>> The display as-is clearly shows that the download is badly bloated, but the upload is fine. That's the important message for most people at home.  But as a researcher, you want to understand the details of the upload. So having different scales would help you see better into the problem.
>> 
>> * If the download and upload values are substantially similar, the left and right Y-axis scales should be the same, so there wouldn't be confusion
>> 
>> * If the values are substantially different (as in this screen shot), the pink and yellow backgrounds (on the left) and the lack of them on the right would provide a solid cue that there is something different going on between the two charts.
>> 
>> * On the other hand, the report already shows different Y-axis values for the down/upload speeds, so the latency charts could mimic the speeds...
>> 
>> Other thoughts?
>> 
>> Rich
>> 
>> On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> 
>> > I wanted to be able to have separated charts for up and down on
>> > different scales, so I took apart what exists today in gimp and got
>> > this:
>> >
>> > http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
>> >
>> > I guess it is partially because I am getting a C on the download at
>> > this speed, and no A+ on the upload, and I would at least like to get
>> > a gold star from teacher for effort. :/
>> >
>> > I dunno how to fix the download short of getting rid of several
>> > seconds of inherent buffering in their CMTS. There must be a simple
>> > way to do that??
>> >
>> > --
>> > 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
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

[-- Attachment #1.2: Type: text/html, Size: 5843 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3089 bytes --]

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 3571 bytes --]

It makes sense.

Or I can just have two Y-Axis with auto-scaling on both.


On Fri, May 22, 2015 at 12:26 AM, Jim Gettys <jg@freedesktop.org> wrote:

>
>
> On Thu, May 21, 2015 at 10:24 AM, Rich Brown <richb.hanover@gmail.com>
> wrote:
>
>> Ahah! I wasn't clear. I do want One Grade to Rule Them All...
>>
>> But I was only talking about different Y-axis values on the latency
>> charts, so that a bad latency in one direction doesn't hide the details of
>> the transfer in the other.
>>
>>
> ​Ah, yes.  That makes sense.
>                      - Jim
> ​
>
>
>> Rich
>>
>> On May 21, 2015, at 10:13 AM, Jim Gettys <jg@freedesktop.org> wrote:
>>
>> Providing separate grades for upload and download does not make sense to
>> me, as interference with acks in the other direction badly hurts that
>> traffic. Uploads and downloads are *not* independent variables.
>>
>> KISS: one grade....
>>                   - Jim
>>
>>
>> On Thu, May 21, 2015 at 9:45 AM, Rich Brown <richb.hanover@gmail.com>
>> wrote:
>>
>>> That is interesting. I'm trying to think how the latency charts could be
>>> misconstrued, since a Y-axis on the right isn't the norm - I don't think
>>> it's hard to understand, but just different.
>>>
>>> The display as-is clearly shows that the download is badly bloated, but
>>> the upload is fine. That's the important message for most people at home.
>>> But as a researcher, you want to understand the details of the upload. So
>>> having different scales would help you see better into the problem.
>>>
>>> * If the download and upload values are substantially similar, the left
>>> and right Y-axis scales should be the same, so there wouldn't be confusion
>>>
>>> * If the values are substantially different (as in this screen shot),
>>> the pink and yellow backgrounds (on the left) and the lack of them on the
>>> right would provide a solid cue that there is something different going on
>>> between the two charts.
>>>
>>> * On the other hand, the report already shows different Y-axis values
>>> for the down/upload speeds, so the latency charts could mimic the speeds...
>>>
>>> Other thoughts?
>>>
>>> Rich
>>>
>>> On May 20, 2015, at 12:46 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> > I wanted to be able to have separated charts for up and down on
>>> > different scales, so I took apart what exists today in gimp and got
>>> > this:
>>> >
>>> > http://snapon.lab.bufferbloat.net/~d/dslreportsmockup.png
>>> >
>>> > I guess it is partially because I am getting a C on the download at
>>> > this speed, and no A+ on the upload, and I would at least like to get
>>> > a gold star from teacher for effort. :/
>>> >
>>> > I dunno how to fix the download short of getting rid of several
>>> > seconds of inherent buffering in their CMTS. There must be a simple
>>> > way to do that??
>>> >
>>> > --
>>> > 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
>>>
>>> _______________________________________________
>>> Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>>
>>
>>
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

[-- Attachment #2: Type: text/html, Size: 6295 bytes --]

Re: [Bloat] dslreports mockup

[Jonathan Morton]

> On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
> 
> Or I can just have two Y-Axis with auto-scaling on both.

You could also try a square-root scale (as opposed to linear or logarithmic).  This should help with comparing data with different orders of magnitude, without flattening things as aggressively as a log scale.

But perhaps we should see what it looks like before committing to it.

 - Jonathan Morton

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

Well the dual Y-Axis thing didn't work.
It would require removal of the color bands and looked confusing.

So I've done a drill-down thing instead. You get just three bars, then can
drill into each by clicking, to see an expansion against its own Y-Axis.
Hard to explain, easier to see:

http://www.dslreports.com/speedtest/525965

On Fri, May 22, 2015 at 10:56 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

>
> > On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
> >
> > Or I can just have two Y-Axis with auto-scaling on both.
>
> You could also try a square-root scale (as opposed to linear or
> logarithmic).  This should help with comparing data with different orders
> of magnitude, without flattening things as aggressively as a log scale.
>
> But perhaps we should see what it looks like before committing to it.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 1533 bytes --]

Re: [Bloat] dslreports mockup

[Sebastian Moeller]

Hi jb,

this looks like a good way to allow easy comparison with the bars and detailed information about the time course, I like it.

On May 22, 2015, at 09:00 , jb <justin@dslr.net> wrote:

> Well the dual Y-Axis thing didn't work.
> It would require removal of the color bands and looked confusing.
> 
> So I've done a drill-down thing instead. You get just three bars, then can 
> drill into each by clicking, to see an expansion against its own Y-Axis.
> Hard to explain, easier to see:
> 
> http://www.dslreports.com/speedtest/525965

	I wonder, would it be possible to also show the last (few) idle data points from just before loading download and upload? That would allow to easily assess how much the latency jumps under load in the drilled down view. Also I think I would like to see the color bands in the bar plot as a first indication whether I need to drill into the detail-views at all ;)

Best Regards
	Sebastian

> 
> On Fri, May 22, 2015 at 10:56 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> > On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
> >
> > Or I can just have two Y-Axis with auto-scaling on both.
> 
> You could also try a square-root scale (as opposed to linear or logarithmic).  This should help with comparing data with different orders of magnitude, without flattening things as aggressively as a log scale.
> 
> But perhaps we should see what it looks like before committing to it.
> 
>  - Jonathan Morton
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Yes, that's a good idea. the library makes it awkward to mix data in one
drill down but I can
mark the idle benchmark somehow, perhaps a green background strip.

It does show bands in the initial view, but they are not visible if none of
the three bars
extends high enough. Since they are averages, and if you get grade A or A+
they don't
tend to extend high enough to show even the yellow band.

I guess I can see the next request: can the "uploading" and "download"
un-exploded
bars not be averages but be maximums.. or close to it ... ?

On Fri, May 22, 2015 at 8:03 PM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi jb,
>
> this looks like a good way to allow easy comparison with the bars and
> detailed information about the time course, I like it.
>
> On May 22, 2015, at 09:00 , jb <justin@dslr.net> wrote:
>
> > Well the dual Y-Axis thing didn't work.
> > It would require removal of the color bands and looked confusing.
> >
> > So I've done a drill-down thing instead. You get just three bars, then
> can
> > drill into each by clicking, to see an expansion against its own Y-Axis.
> > Hard to explain, easier to see:
> >
> > http://www.dslreports.com/speedtest/525965
>
>         I wonder, would it be possible to also show the last (few) idle
> data points from just before loading download and upload? That would allow
> to easily assess how much the latency jumps under load in the drilled down
> view. Also I think I would like to see the color bands in the bar plot as a
> first indication whether I need to drill into the detail-views at all ;)
>
> Best Regards
>         Sebastian
>
> >
> > On Fri, May 22, 2015 at 10:56 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
> >
> > > On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
> > >
> > > Or I can just have two Y-Axis with auto-scaling on both.
> >
> > You could also try a square-root scale (as opposed to linear or
> logarithmic).  This should help with comparing data with different orders
> of magnitude, without flattening things as aggressively as a log scale.
> >
> > But perhaps we should see what it looks like before committing to it.
> >
> >  - Jonathan Morton
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>

[-- Attachment #2: Type: text/html, Size: 3467 bytes --]

Re: [Bloat] dslreports mockup

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 268 bytes --]

On 22/05/2015 13:52, jb wrote:
>
> I guess I can see the next request: can the "uploading" and "download" un-exploded
> bars not be averages but be maximums.. or close to it ... ?

Show both - solid bar shows peak, marker line across bar shows average.

Kevin

[-- Attachment #1.2: Type: text/html, Size: 1033 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] dslreports mockup

[Sebastian Moeller]

Hi jb,


On May 22, 2015, at 14:52 , jb <justin@dslr.net> wrote:

> Yes, that's a good idea. the library makes it awkward to mix data in one drill down but I can
> mark the idle benchmark somehow, perhaps a green background strip.

	That would work well for me ;)

> 
> It does show bands in the initial view, but they are not visible if none of the three bars
> extends high enough.

	Fair enough, I guess most important in the bar view is the direct comparison of the aggregate measures...

> Since they are averages, and if you get grade A or A+ they don't
> tend to extend high enough to show even the yellow band.
> 
> I guess I can see the next request: can the "uploading" and "download" un-exploded
> bars not be averages but be maximums.. or close to it … ?

	Bull’s eye ;) the war I see stats is that if one reports a mean value one also needs to report a variance measure, preferably a confidence limit (say 95% or even 99% ). But the RTT values (under load) decidedly are not normally distributed, so the mean might not be the best measure to begin with (maybe mean and skewness would work, the higher the skewness the worse the buffer bloat grade)...


Best regards
	Sebatian



> 
> On Fri, May 22, 2015 at 8:03 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi jb,
> 
> this looks like a good way to allow easy comparison with the bars and detailed information about the time course, I like it.
> 
> On May 22, 2015, at 09:00 , jb <justin@dslr.net> wrote:
> 
> > Well the dual Y-Axis thing didn't work.
> > It would require removal of the color bands and looked confusing.
> >
> > So I've done a drill-down thing instead. You get just three bars, then can
> > drill into each by clicking, to see an expansion against its own Y-Axis.
> > Hard to explain, easier to see:
> >
> > http://www.dslreports.com/speedtest/525965
> 
>         I wonder, would it be possible to also show the last (few) idle data points from just before loading download and upload? That would allow to easily assess how much the latency jumps under load in the drilled down view. Also I think I would like to see the color bands in the bar plot as a first indication whether I need to drill into the detail-views at all ;)
> 
> Best Regards
>         Sebastian
> 
> >
> > On Fri, May 22, 2015 at 10:56 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
> >
> > > On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
> > >
> > > Or I can just have two Y-Axis with auto-scaling on both.
> >
> > You could also try a square-root scale (as opposed to linear or logarithmic).  This should help with comparing data with different orders of magnitude, without flattening things as aggressively as a log scale.
> >
> > But perhaps we should see what it looks like before committing to it.
> >
> >  - Jonathan Morton
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> 
> 

Re: [Bloat] dslreports mockup

[Dave Taht]

On Fri, May 22, 2015 at 12:00 AM, jb <justin@dslr.net> wrote:
> Well the dual Y-Axis thing didn't work.
> It would require removal of the color bands and looked confusing.

k.

> So I've done a drill-down thing instead. You get just three bars, then can
> drill into each by clicking, to see an expansion against its own Y-Axis.
> Hard to explain, easier to see:
>
> http://www.dslreports.com/speedtest/525965

1) It shows "series 2" for the drill downs rather than upload/download/idle.

2) I am not big on averages, period. showing min/median/max on the bar chart
is more satisfying to me, (see relevant netperf-wrapper plottype), but I know
that too is confusing to users.

Saying "average bloat" is sort of like saying this drug only kills 2%
of people on average - it might be accurate statistically (except for
missing a long term trendline and not coping with different RTTs
well), but it does tend to matter to those it kills.

I know tons of people like plain old bar charts, but...

3) I like how this drilldown and the previous detailed graphs shows
the queues building over the course of the test. This lends intuition
to the problem (and shows the trendline in particular)

Perhaps something that would be interesting would be for the drill
down to instead
swap between graphs over an interval (every few seconds), then stop on the
worst one after 20 seconds....

going back to the first screen of the test actually running:

4) The radar ping plot is boring after the test starts, and on a small
laptop the bufferbloat
"tach" is invisible. I would remove the radar ping plot after the test
starts and stick the
bloat tach there instead.

Aint I demanding?

5) (this is still marvellous work and deepest gratitude, and so on,
and thanks for playing with us)

6) we are so losing on inbound at the moment.

http://www.dslreports.com/speedtest/529300

7) I hope to add some tests to the finally renamed flent (formerly
netperf-wrapper) that will more closely duplicate your tests. In
particular, I want to add support for many different remote servers to
all the basic tests. You have clearly pointed out that we need to
tackle that,  and see items 5, and 6...

Are you settled on 16/6 for the basic "cable" test, in particular?


> On Fri, May 22, 2015 at 10:56 AM, Jonathan Morton <chromatix99@gmail.com>
> wrote:
>>
>>
>> > On 22 May, 2015, at 03:17, jb <justin@dslr.net> wrote:
>> >
>> > Or I can just have two Y-Axis with auto-scaling on both.
>>
>> You could also try a square-root scale (as opposed to linear or
>> logarithmic).  This should help with comparing data with different orders of
>> magnitude, without flattening things as aggressively as a log scale.
>>
>> But perhaps we should see what it looks like before committing to it.
>>
>>  - Jonathan Morton
>>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] dslreports mockup

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 592 bytes --]

On Thu, 21 May 2015, Jim Gettys wrote:

> Providing separate grades for upload and download does not make sense to
> me, as interference with acks in the other direction badly hurts that
> traffic. Uploads and downloads are *not* independent variables.
>
> KISS: one grade....
>                  - Jim

yes and no.

If I am getting a bad grade, will replacing my local router help? or is all the 
problem on the ISPs equipment?

having upload getting an A+ due to running good, debloated systems locally, but 
the download getting a F due to the ISP buffering would be meaningful.

David Lang

[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

I can add error bars to the combined columns. I think that will help.

On Sat, May 23, 2015 at 10:55 AM, David Lang <david@lang.hm> wrote:

> On Thu, 21 May 2015, Jim Gettys wrote:
>
>  Providing separate grades for upload and download does not make sense to
>> me, as interference with acks in the other direction badly hurts that
>> traffic. Uploads and downloads are *not* independent variables.
>>
>> KISS: one grade....
>>                  - Jim
>>
>
> yes and no.
>
> If I am getting a bad grade, will replacing my local router help? or is
> all the problem on the ISPs equipment?
>
> having upload getting an A+ due to running good, debloated systems
> locally, but the download getting a F due to the ISP buffering would be
> meaningful.
>
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

[-- Attachment #2: Type: text/html, Size: 1869 bytes --]

Re: [Bloat] dslreports mockup

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 287 bytes --]

On 23/05/2015 02:56, jb wrote:
> I can add error bars to the combined columns. I think that will help.

Seen it.  Very nice.  Especially like clicking on 'Phases', expands the scale out.

Not sure I understand the 'Series 3' that's displayed when expanding a graph out though?



[-- Attachment #1.2: Type: text/html, Size: 833 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

The label when you click isn't my choice, its applied by the
chart library I just haven't worked out how to fix it yet :/

On Sun, May 24, 2015 at 5:35 AM, Kevin Darbyshire-Bryant <
kevin@darbyshire-bryant.me.uk> wrote:

>  On 23/05/2015 02:56, jb wrote:
>
> I can add error bars to the combined columns. I think that will help.
>
>
> Seen it.  Very nice.  Especially like clicking on 'Phases', expands the
> scale out.
>
> Not sure I understand the 'Series 3' that's displayed when expanding a
> graph out though?
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>

[-- Attachment #2: Type: text/html, Size: 1409 bytes --]

Re: [Bloat] dslreports mockup

[Sebastian Moeller]

Hi jb,


On May 23, 2015, at 03:56 , jb <justin@dslr.net> wrote:

> I can add error bars to the combined columns. I think that will help.

	This is quite helpful, what exactly are the “error bars” showing? I would vote for 2 and 98 percent qantiles. I note that I have seen several times that both error bars (low and high) of the idle category seems to be displayed above the bar, like levitating above the bar. Could be display error on my end, but I guess the bars show something meaningful and I just do not know how to parse it correctly…

Best Regards
	Sebastian

> 
> On Sat, May 23, 2015 at 10:55 AM, David Lang <david@lang.hm> wrote:
> On Thu, 21 May 2015, Jim Gettys wrote:
> 
> Providing separate grades for upload and download does not make sense to
> me, as interference with acks in the other direction badly hurts that
> traffic. Uploads and downloads are *not* independent variables.
> 
> KISS: one grade....
>                  - Jim
> 
> yes and no.
> 
> If I am getting a bad grade, will replacing my local router help? or is all the problem on the ISPs equipment?
> 
> having upload getting an A+ due to running good, debloated systems locally, but the download getting a F due to the ISP buffering would be meaningful.
> 
> David Lang
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] dslreports mockup

[Dave Taht]

On Sat, May 23, 2015 at 2:43 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi jb,
>
>
> On May 23, 2015, at 03:56 , jb <justin@dslr.net> wrote:
>
>> I can add error bars to the combined columns. I think that will help.
>
>         This is quite helpful, what exactly are the “error bars” showing?

I am loving seeing the error bars. The general public won't understand
them but a ton of other people do, and I can live with that.

and loving being able to click on the bars for more detail.

Aside from wanting:

A) the grade center/top  as per the mockup.
B) some more apparent indicator of the detailed graphs available (like
rotating between them on initial view)
C) the bloat tach front and center during the test
D) the different number of flows tests NOT broken up by "technology"
but by extremity, and calling out wifi VERY explicitly
(I can do a mock up of this if my prior description was not good enough)
E) World Peace

I'm pretty happy with this (and just in awe of how much work is
required to deploy a web browser based application)

>I would vote for 2 and 98 percent qantiles.

I think these are max and min, unfiltered. There are not enough
samples in the default test (1/sec) to get higher resolution (although
I run the hires bloat test and would certainly prefer that a minimum
of 100ms sampling rate was used for all - 20ms would be better). But 2
and 98 if possible would be better than max/min, (with sufficient
samples).

http://en.wikipedia.org/wiki/Seven-number_summary is fun because it
depends on a normally distributed model, which this stuff isn't. (I'd
like to see this for flent, also)

I would like to see the algorithm(s) for this documented sufficiently
somewhere... (and to finish duplicating the work in flent)

>I note that I have seen several times that both error bars (low and high) of the idle category seems to be displayed above the bar, like levitating above the bar. Could be display error on my end, but I guess the bars show something meaningful and I just do not know how to parse it correctly…
>
> Best Regards
>         Sebastian
>
>>
>> On Sat, May 23, 2015 at 10:55 AM, David Lang <david@lang.hm> wrote:
>> On Thu, 21 May 2015, Jim Gettys wrote:
>>
>> Providing separate grades for upload and download does not make sense to
>> me, as interference with acks in the other direction badly hurts that
>> traffic. Uploads and downloads are *not* independent variables.
>>
>> KISS: one grade....
>>                  - Jim
>>
>> yes and no.
>>
>> If I am getting a bad grade, will replacing my local router help? or is all the problem on the ISPs equipment?
>>
>> having upload getting an A+ due to running good, debloated systems locally, but the download getting a F due to the ISP buffering would be meaningful.
>>
>> David Lang
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] dslreports mockup

[jb]

[-- Attachment #1: Type: text/plain, Size: 4952 bytes --]

I did move the half-moon gauge up into the green "ping" block.

Over time the intention will be to grade a result on more than one
category, not just for buffer bloat. For example, recognition of
excessive latency to everywhere, or a poor speed compared to peers
in the same country on the same tech, or incorporation of the jitter
test result, or other yet to be determined metrics. Then an over-all
grade that is a summation of everything because people want
one answer: is my connection good or not right now, & has it got worse
over time? or better. Putting a buffer bloat grade front and centre
makes it purely a buffer-bloat test.

So I'll probably have to re-arrange the positioning of grades and so
on, and probably also have to stop calling it a "speed test" as well
because the speed race is probably over with imminent availability
of home connections faster than one can reasonably use. The median
connection speed for fios or comcast users running the test is about
50 mbit. Most of those connections are idle all day.

On Mon, May 25, 2015 at 2:58 AM, Dave Taht <dave.taht@gmail.com> wrote:

> On Sat, May 23, 2015 at 2:43 PM, Sebastian Moeller <moeller0@gmx.de>
> wrote:
> > Hi jb,
> >
> >
> > On May 23, 2015, at 03:56 , jb <justin@dslr.net> wrote:
> >
> >> I can add error bars to the combined columns. I think that will help.
> >
> >         This is quite helpful, what exactly are the “error bars” showing?
>
> I am loving seeing the error bars. The general public won't understand
> them but a ton of other people do, and I can live with that.
>
> and loving being able to click on the bars for more detail.
>
> Aside from wanting:
>
> A) the grade center/top  as per the mockup.
> B) some more apparent indicator of the detailed graphs available (like
> rotating between them on initial view)
> C) the bloat tach front and center during the test
> D) the different number of flows tests NOT broken up by "technology"
> but by extremity, and calling out wifi VERY explicitly
> (I can do a mock up of this if my prior description was not good enough)
> E) World Peace
>
> I'm pretty happy with this (and just in awe of how much work is
> required to deploy a web browser based application)
>
> >I would vote for 2 and 98 percent qantiles.
>
> I think these are max and min, unfiltered. There are not enough
> samples in the default test (1/sec) to get higher resolution (although
> I run the hires bloat test and would certainly prefer that a minimum
> of 100ms sampling rate was used for all - 20ms would be better). But 2
> and 98 if possible would be better than max/min, (with sufficient
> samples).
>
> http://en.wikipedia.org/wiki/Seven-number_summary is fun because it
> depends on a normally distributed model, which this stuff isn't. (I'd
> like to see this for flent, also)
>
> I would like to see the algorithm(s) for this documented sufficiently
> somewhere... (and to finish duplicating the work in flent)
>
> >I note that I have seen several times that both error bars (low and high)
> of the idle category seems to be displayed above the bar, like levitating
> above the bar. Could be display error on my end, but I guess the bars show
> something meaningful and I just do not know how to parse it correctly…
> >
> > Best Regards
> >         Sebastian
> >
> >>
> >> On Sat, May 23, 2015 at 10:55 AM, David Lang <david@lang.hm> wrote:
> >> On Thu, 21 May 2015, Jim Gettys wrote:
> >>
> >> Providing separate grades for upload and download does not make sense to
> >> me, as interference with acks in the other direction badly hurts that
> >> traffic. Uploads and downloads are *not* independent variables.
> >>
> >> KISS: one grade....
> >>                  - Jim
> >>
> >> yes and no.
> >>
> >> If I am getting a bad grade, will replacing my local router help? or is
> all the problem on the ISPs equipment?
> >>
> >> having upload getting an A+ due to running good, debloated systems
> locally, but the download getting a F due to the ISP buffering would be
> meaningful.
> >>
> >> David Lang
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >>
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >>
> >>
> >> _______________________________________________
> >> Bloat mailing list
> >> Bloat@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>

[-- Attachment #2: Type: text/html, Size: 6855 bytes --]