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

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

[Dave Taht]

https://plus.google.com/u/0/107942175615993706558/posts/ZytYb4ZkMdY

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

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

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

[jb]

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

If the tool were to list ISPs in descending order of a bloaty factor from
best (like this
one)   http://www.dslreports.com/speedtest/375736
to worst (like I don't know yet), what would be the ranking factor?

Call B the "blue" series of latencies.
Call G the "idle" series
Call O the "orange" series

What is fn1(fn2(B),fn2(G),fn2(O)) that generates an open-ended bloat
factor, where 0 is no problem ?
What is fn1() that takes a series of latencies and produces one latency?
What is fn1() that takes three latencies, and produces a bloat factor?

And then having obtained a "bloat factor" for one result, do you combine
them using an average?

Also should there be another input such as connection speed.
Should higher speed lines be held to a higher standard?

The "bloat factor" can be what is reported next to Ping on a test result.
Should it be an infinite set of numbers from 0 .. infinity or should it be
a grade
A+ down to F ?
(a grade would be more user-friendly).

On Wed, Apr 29, 2015 at 12:48 AM, Dave Taht <dave.taht@gmail.com> wrote:

> https://plus.google.com/u/0/107942175615993706558/posts/ZytYb4ZkMdY
>
> --
> 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
>

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

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

[David Lang]

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

On Wed, 29 Apr 2015, jb wrote:

> If the tool were to list ISPs in descending order of a bloaty factor from
> best (like this
> one)   http://www.dslreports.com/speedtest/375736
> to worst (like I don't know yet), what would be the ranking factor?

I think the biggest problem is differentiating between bloat on the ISP side and 
bloat on the endpoint router. A given ISP may have very good internal setups, 
but bad/obsolete equipment at the endpoints, or the endpoints could be upgraded 
and the ISP could still have problems on their side.

> Call B the "blue" series of latencies.
> Call G the "idle" series
> Call O the "orange" series
>
> What is fn1(fn2(B),fn2(G),fn2(O)) that generates an open-ended bloat
> factor, where 0 is no problem ?
> What is fn1() that takes a series of latencies and produces one latency?
> What is fn1() that takes three latencies, and produces a bloat factor?
>
> And then having obtained a "bloat factor" for one result, do you combine
> them using an average?
>
> Also should there be another input such as connection speed.
> Should higher speed lines be held to a higher standard?

if you measure the bloat as the difference from idle, then using one standard 
for all speeds should be reasonable.

> The "bloat factor" can be what is reported next to Ping on a test result.
> Should it be an infinite set of numbers from 0 .. infinity or should it be
> a grade
> A+ down to F ?
> (a grade would be more user-friendly).

I think A+ down to F is good. based on our jitter discussion,

A+ <5ms
A <30ms
B <60ms
C <200ms
D <400ms
F >400ms

or something like this (so that not all situations result in A+ or F)

David Lang

> On Wed, Apr 29, 2015 at 12:48 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
>> https://plus.google.com/u/0/107942175615993706558/posts/ZytYb4ZkMdY
>>
>> --
>> 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
>>
>

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

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

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

[Jonathan Morton]

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

These are pretty good questions, actually. But as pointed out, when you
want to start ranking, it's important to distinguish the performance of the
ISP itself from equipment under the subscriber's control, which itself
might be configured to hide faults in the ISP.

Statistics is a hard subject. If you feel at all confused by what I
describe below, it might be a good idea to sit down with a real expert. The
basic calculations are not difficult; it's knowing WHAT to calculate and
what it means once you've done it.

Notably, the upload queue usually depends much more on the CPE than on
anything the ISP controls directly. I don't think there are that many ISPs
left which absolutely insist on using their own modem, but most will supply
a preferred, preconfigured model on request, and many users will accept
that, not knowing better. Unfortunately, I can't think of an easy, robust
way to detect what CPE is in use our how it has been configured, so it's
hard to control for it statistically.

In general, downstream queuing is much more under the ISP's control. To
account for the (growing?) subset of users who apply ingress shaping, you
could look at the upper percentiles of latency, since usually ingress
shaping will improve matters. Caveat: it's also possible for ingress
shaping to make things worse, either through accidental misconfiguration or
even maliciously, so don't just take the peak value.

Initially I suggest you present a histogram of the results that fall into
particular grades. That'll help you get a feel for the statistics, and it's
easy to pick out a modal value by eye. Beware of trying to calculate a
modal value simplistically, since the histogram might not show a simple
mode if results tend to straddle two adjacent grades. (This is why the mode
is the least used of the three basic averages; it's hard to calculate it
such that it's reliably useful, even though it's often intuitively useful.)

I also suggest you add a basic question to the user: are you using a router
with QoS features turned on (yes/no/dunno), with dunno as the default.
That'll give you a way to point out that most of the lower latency results
are probably a result of this. You could draw stacked or adjacent
histograms with this information colour coded.

As for the single numbers to plug into the formula, this also requires some
care.

For the idle/baseline, I suggest using only the samples from before the
bandwidth tests begin, rather than also including those from between and
afterwards. Then you should use the harmonic mean on these, to get a value
biased on the low end.

For each of the load sets, you want a value biased high. Taking the 90th
percentile might be a reasonable approach here; it'll discard outliers and
brief transients that a good AQM acting alone (ie. without FQ) might leave,
but should still expose the sorts of obvious problems that we're trying to
tackle.

I do think that the idle latency and the total loaded latency can usefully
be reported as frequencies. The total loaded latency can be taken to be the
idle latency plus the induced download latency plus the induced upload
latency, as an approximation of the latency when both directions are loaded
at once.

As for ranking ISPs overall... this is hard to do in a way that's perceived
to be fair. My recommendation on this front would be to allow your users to
select criteria with weights. Some might consider download and/or upload
speed to be important as well as latency, while others might see a choice
between overall latency (important for games) and jitter (important for
VoIP). This makes it harder to claim that you're personally presenting a
controversial opinion on relative merits.

- Jonathan Morton

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

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

[Dave Taht]

my short term answer is to ask you merely collect lots more data and
slice it up different ways, trying to isolate actual browser bugs from
actual data (and NOT discarding what appears to be outliers, because
the outliers are interesting - I am perpetually thinking of the
discovery of the cosmic background radiation when it comes to looking
at bufferbloat stuff), then work the raw data with one or more of the
folk here (under NDA, I would assume) to get aggregate stats that make
sense and are publishable.

Some things that may help:

A) You can be generally assured that anything that has ECT(3) asserted
on the header is coming from a aqm-enabled router. There are also ack
markings for that, not in the header. (are you also getting captures?)

B) Nearly anything from free.fr will be either SFQed or FQ_Codeled

C) Hopefully your users will distinguish wifi from non wifi
connections but that seems dicey.

D) We can add tests as similar to yours as possible as yours evolve,
to the netperf-wrapper suite so as to get comparisons from our tools,
without having a browser/web server/vm to deal with.

I would like (after seeing it finally, on OSX) for the bufferbloat
dial to be front and center instead of the static ping radar image.


On Tue, Apr 28, 2015 at 6:39 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
> These are pretty good questions, actually. But as pointed out, when you want
> to start ranking, it's important to distinguish the performance of the ISP
> itself from equipment under the subscriber's control, which itself might be
> configured to hide faults in the ISP.
>
> Statistics is a hard subject. If you feel at all confused by what I describe
> below, it might be a good idea to sit down with a real expert. The basic
> calculations are not difficult; it's knowing WHAT to calculate and what it
> means once you've done it.
>
> Notably, the upload queue usually depends much more on the CPE than on
> anything the ISP controls directly. I don't think there are that many ISPs
> left which absolutely insist on using their own modem, but most will supply
> a preferred, preconfigured model on request, and many users will accept
> that, not knowing better. Unfortunately, I can't think of an easy, robust
> way to detect what CPE is in use our how it has been configured, so it's
> hard to control for it statistically.
>
> In general, downstream queuing is much more under the ISP's control. To
> account for the (growing?) subset of users who apply ingress shaping, you
> could look at the upper percentiles of latency, since usually ingress
> shaping will improve matters. Caveat: it's also possible for ingress shaping
> to make things worse, either through accidental misconfiguration or even
> maliciously, so don't just take the peak value.
>
> Initially I suggest you present a histogram of the results that fall into
> particular grades. That'll help you get a feel for the statistics, and it's
> easy to pick out a modal value by eye. Beware of trying to calculate a modal
> value simplistically, since the histogram might not show a simple mode if
> results tend to straddle two adjacent grades. (This is why the mode is the
> least used of the three basic averages; it's hard to calculate it such that
> it's reliably useful, even though it's often intuitively useful.)
>
> I also suggest you add a basic question to the user: are you using a router
> with QoS features turned on (yes/no/dunno), with dunno as the default.
> That'll give you a way to point out that most of the lower latency results
> are probably a result of this. You could draw stacked or adjacent histograms
> with this information colour coded.
>
> As for the single numbers to plug into the formula, this also requires some
> care.
>
> For the idle/baseline, I suggest using only the samples from before the
> bandwidth tests begin, rather than also including those from between and
> afterwards. Then you should use the harmonic mean on these, to get a value
> biased on the low end.
>
> For each of the load sets, you want a value biased high. Taking the 90th
> percentile might be a reasonable approach here; it'll discard outliers and
> brief transients that a good AQM acting alone (ie. without FQ) might leave,
> but should still expose the sorts of obvious problems that we're trying to
> tackle.
>
> I do think that the idle latency and the total loaded latency can usefully
> be reported as frequencies. The total loaded latency can be taken to be the
> idle latency plus the induced download latency plus the induced upload
> latency, as an approximation of the latency when both directions are loaded
> at once.
>
> As for ranking ISPs overall... this is hard to do in a way that's perceived
> to be fair. My recommendation on this front would be to allow your users to
> select criteria with weights. Some might consider download and/or upload
> speed to be important as well as latency, while others might see a choice
> between overall latency (important for games) and jitter (important for
> VoIP). This makes it harder to claim that you're personally presenting a
> controversial opinion on relative merits.
>
> - 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] extremely good dslreports result for bufferbloat on free.fr

[jb]

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

Ok thanks

I think I will stay away from the quagmire of rating ISPs on buffer bloat.

And first try to boil any bloat measurement down to an easy to understand
letter grade
between A+ and F, in a way that you guys think stands inspection of
individual
results.

On Wed, Apr 29, 2015 at 11:39 AM, Jonathan Morton <chromatix99@gmail.com>
wrote:

> These are pretty good questions, actually. But as pointed out, when you
> want to start ranking, it's important to distinguish the performance of the
> ISP itself from equipment under the subscriber's control, which itself
> might be configured to hide faults in the ISP.
>
> Statistics is a hard subject. If you feel at all confused by what I
> describe below, it might be a good idea to sit down with a real expert. The
> basic calculations are not difficult; it's knowing WHAT to calculate and
> what it means once you've done it.
>
> Notably, the upload queue usually depends much more on the CPE than on
> anything the ISP controls directly. I don't think there are that many ISPs
> left which absolutely insist on using their own modem, but most will supply
> a preferred, preconfigured model on request, and many users will accept
> that, not knowing better. Unfortunately, I can't think of an easy, robust
> way to detect what CPE is in use our how it has been configured, so it's
> hard to control for it statistically.
>
> In general, downstream queuing is much more under the ISP's control. To
> account for the (growing?) subset of users who apply ingress shaping, you
> could look at the upper percentiles of latency, since usually ingress
> shaping will improve matters. Caveat: it's also possible for ingress
> shaping to make things worse, either through accidental misconfiguration or
> even maliciously, so don't just take the peak value.
>
> Initially I suggest you present a histogram of the results that fall into
> particular grades. That'll help you get a feel for the statistics, and it's
> easy to pick out a modal value by eye. Beware of trying to calculate a
> modal value simplistically, since the histogram might not show a simple
> mode if results tend to straddle two adjacent grades. (This is why the mode
> is the least used of the three basic averages; it's hard to calculate it
> such that it's reliably useful, even though it's often intuitively useful.)
>
> I also suggest you add a basic question to the user: are you using a
> router with QoS features turned on (yes/no/dunno), with dunno as the
> default. That'll give you a way to point out that most of the lower latency
> results are probably a result of this. You could draw stacked or adjacent
> histograms with this information colour coded.
>
> As for the single numbers to plug into the formula, this also requires
> some care.
>
> For the idle/baseline, I suggest using only the samples from before the
> bandwidth tests begin, rather than also including those from between and
> afterwards. Then you should use the harmonic mean on these, to get a value
> biased on the low end.
>
> For each of the load sets, you want a value biased high. Taking the 90th
> percentile might be a reasonable approach here; it'll discard outliers and
> brief transients that a good AQM acting alone (ie. without FQ) might leave,
> but should still expose the sorts of obvious problems that we're trying to
> tackle.
>
> I do think that the idle latency and the total loaded latency can usefully
> be reported as frequencies. The total loaded latency can be taken to be the
> idle latency plus the induced download latency plus the induced upload
> latency, as an approximation of the latency when both directions are loaded
> at once.
>
> As for ranking ISPs overall... this is hard to do in a way that's
> perceived to be fair. My recommendation on this front would be to allow
> your users to select criteria with weights. Some might consider download
> and/or upload speed to be important as well as latency, while others might
> see a choice between overall latency (important for games) and jitter
> (important for VoIP). This makes it harder to claim that you're personally
> presenting a controversial opinion on relative merits.
>
> - Jonathan Morton
>

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

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

[Juliusz Chroboczek]

Free.fr (Proxad) is certainly much better than other ISPs -- they've been
the first to give sort-of-native (6rd) IPv6 to the masses.  However,
there's one thing that annoys me -- they have two distinct CPEs, the
classic FreeBox (which I have) and the FreeBox Revolution (which is
slightly less cheap, and takes more physical space -- a big deal if you
live in Paris).  The classic FreeBox needs some love from the firmware
developers, and I'd be curious to know whether your results apply equally
to both boxen.

(The thing that most pisses me off with the classic FreeBox is that it
doesn't allow IPv6 subnetting -- unless you order the FreeBox Revolution,
you're condemned to the purgatory of ND-proxying.  Grr.)

-- Juliusz

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

[Dave Taht]

On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
<jch@pps.univ-paris-diderot.fr> wrote:
> Free.fr (Proxad) is certainly much better than other ISPs -- they've been
> the first to give sort-of-native (6rd) IPv6 to the masses.  However,
> there's one thing that annoys me -- they have two distinct CPEs, the
> classic FreeBox (which I have) and the FreeBox Revolution (which is
> slightly less cheap, and takes more physical space -- a big deal if you
> live in Paris).  The classic FreeBox needs some love from the firmware
> developers, and I'd be curious to know whether your results apply equally
> to both boxen.

All ya gotta do is run the new dslreports and/or rrul test(s) on your
own older box, and post. ;)

My understanding was that the old freebox was too weak to run anything
but SFQ, but it did run that on the outbound.

>
> (The thing that most pisses me off with the classic FreeBox is that it
> doesn't allow IPv6 subnetting -- unless you order the FreeBox Revolution,
> you're condemned to the purgatory of ND-proxying.  Grr.)

As tiny as the mods now are to support more extensive ipv6 in openwrt,
that certainly was not the case in 2012.

>
> -- Juliusz



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

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

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

[Dave Taht]

Heh. Anything above a 250ms gets a F from me. But I strongly approve
of simplification to a set of grades.

http://www.dslreports.com/speedtest/378980 F, for sure.

Secondly, we tend to regard bufferbloat as one word not two.

This result got no rating. http://www.dslreports.com/speedtest/377563

On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
> I've added the discussed "bloat rating".
>
> It takes the idle period before download uses the lowest latency as a
> baseline.
> then it takes the median download and median of upload+trailing idle time,
> and
> subtracts to get the latency increase, then converts to a grade.
>
> Based on a very few results I've looked at the Grade seems reasonable. I've
> added
> a link below the grade for the WTF is this moment a lot of people will have,
> which
> takes them to a short FAQ entry, and then a link to bufferbloat.net ..
>
>
> On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
>> <jch@pps.univ-paris-diderot.fr> wrote:
>> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
>> > been
>> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
>> > there's one thing that annoys me -- they have two distinct CPEs, the
>> > classic FreeBox (which I have) and the FreeBox Revolution (which is
>> > slightly less cheap, and takes more physical space -- a big deal if you
>> > live in Paris).  The classic FreeBox needs some love from the firmware
>> > developers, and I'd be curious to know whether your results apply
>> > equally
>> > to both boxen.
>>
>> All ya gotta do is run the new dslreports and/or rrul test(s) on your
>> own older box, and post. ;)
>>
>> My understanding was that the old freebox was too weak to run anything
>> but SFQ, but it did run that on the outbound.
>>
>> >
>> > (The thing that most pisses me off with the classic FreeBox is that it
>> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
>> > Revolution,
>> > you're condemned to the purgatory of ND-proxying.  Grr.)
>>
>> As tiny as the mods now are to support more extensive ipv6 in openwrt,
>> that certainly was not the case in 2012.
>>
>> >
>> > -- Juliusz
>>
>>
>>
>> --
>> 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
>
>



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

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

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

[jb]

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

yes it did get no rating, I don't generate ratings unless everything looks
"right",
meaning a decent number of down idle and up pings.

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

There are only 6 latency samples during download, even though the download
phase started at the 12 second mark and continued until the 23 second mark,
(meaning 11 seconds).

The latency pings that happened during the download got held up to the
extent
that they came in and were counted as "idle" ones. I'll have to ponder on
this,
I think my pings need to be labelled by origin (what we were doing when they
were sent) not classified as they return.

if it did get a rating it would be an "D" or "F"..


On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com> wrote:

> Heh. Anything above a 250ms gets a F from me. But I strongly approve
> of simplification to a set of grades.
>
> http://www.dslreports.com/speedtest/378980 F, for sure.
>
> Secondly, we tend to regard bufferbloat as one word not two.
>
> This result got no rating. http://www.dslreports.com/speedtest/377563
>
> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
> > I've added the discussed "bloat rating".
> >
> > It takes the idle period before download uses the lowest latency as a
> > baseline.
> > then it takes the median download and median of upload+trailing idle
> time,
> > and
> > subtracts to get the latency increase, then converts to a grade.
> >
> > Based on a very few results I've looked at the Grade seems reasonable.
> I've
> > added
> > a link below the grade for the WTF is this moment a lot of people will
> have,
> > which
> > takes them to a short FAQ entry, and then a link to bufferbloat.net ..
> >
> >
> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
> >>
> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
> >> <jch@pps.univ-paris-diderot.fr> wrote:
> >> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
> >> > been
> >> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
> >> > there's one thing that annoys me -- they have two distinct CPEs, the
> >> > classic FreeBox (which I have) and the FreeBox Revolution (which is
> >> > slightly less cheap, and takes more physical space -- a big deal if
> you
> >> > live in Paris).  The classic FreeBox needs some love from the firmware
> >> > developers, and I'd be curious to know whether your results apply
> >> > equally
> >> > to both boxen.
> >>
> >> All ya gotta do is run the new dslreports and/or rrul test(s) on your
> >> own older box, and post. ;)
> >>
> >> My understanding was that the old freebox was too weak to run anything
> >> but SFQ, but it did run that on the outbound.
> >>
> >> >
> >> > (The thing that most pisses me off with the classic FreeBox is that it
> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
> >> > Revolution,
> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
> >>
> >> As tiny as the mods now are to support more extensive ipv6 in openwrt,
> >> that certainly was not the case in 2012.
> >>
> >> >
> >> > -- Juliusz
> >>
> >>
> >>
> >> --
> >> 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
> >
> >
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>

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

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

[Dave Taht]

A: (fq_codel no ecn) (http://www.dslreports.com/speedtest/393466

A+ (fq_codel + ecn was enabled) http://www.dslreports.com/speedtest/393300

A: (fq_codel) http://www.dslreports.com/speedtest/393241

A: (fq_codel) http://www.dslreports.com/speedtest/391178

D: (fq_codel on the link but over wifi)
http://www.dslreports.com/speedtest/391178

Lemme go check native comcast and pie....


On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
> yes it did get no rating, I don't generate ratings unless everything looks
> "right",
> meaning a decent number of down idle and up pings.
>
> http://www.dslreports.com/speedtest/377563
>
> There are only 6 latency samples during download, even though the download
> phase started at the 12 second mark and continued until the 23 second mark,
> (meaning 11 seconds).
>
> The latency pings that happened during the download got held up to the
> extent
> that they came in and were counted as "idle" ones. I'll have to ponder on
> this,
> I think my pings need to be labelled by origin (what we were doing when they
> were sent) not classified as they return.
>
> if it did get a rating it would be an "D" or "F"..
>
>
> On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Heh. Anything above a 250ms gets a F from me. But I strongly approve
>> of simplification to a set of grades.
>>
>> http://www.dslreports.com/speedtest/378980 F, for sure.
>>
>> Secondly, we tend to regard bufferbloat as one word not two.
>>
>> This result got no rating. http://www.dslreports.com/speedtest/377563
>>
>> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
>> > I've added the discussed "bloat rating".
>> >
>> > It takes the idle period before download uses the lowest latency as a
>> > baseline.
>> > then it takes the median download and median of upload+trailing idle
>> > time,
>> > and
>> > subtracts to get the latency increase, then converts to a grade.
>> >
>> > Based on a very few results I've looked at the Grade seems reasonable.
>> > I've
>> > added
>> > a link below the grade for the WTF is this moment a lot of people will
>> > have,
>> > which
>> > takes them to a short FAQ entry, and then a link to bufferbloat.net ..
>> >
>> >
>> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>
>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
>> >> <jch@pps.univ-paris-diderot.fr> wrote:
>> >> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
>> >> > been
>> >> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
>> >> > there's one thing that annoys me -- they have two distinct CPEs, the
>> >> > classic FreeBox (which I have) and the FreeBox Revolution (which is
>> >> > slightly less cheap, and takes more physical space -- a big deal if
>> >> > you
>> >> > live in Paris).  The classic FreeBox needs some love from the
>> >> > firmware
>> >> > developers, and I'd be curious to know whether your results apply
>> >> > equally
>> >> > to both boxen.
>> >>
>> >> All ya gotta do is run the new dslreports and/or rrul test(s) on your
>> >> own older box, and post. ;)
>> >>
>> >> My understanding was that the old freebox was too weak to run anything
>> >> but SFQ, but it did run that on the outbound.
>> >>
>> >> >
>> >> > (The thing that most pisses me off with the classic FreeBox is that
>> >> > it
>> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
>> >> > Revolution,
>> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
>> >>
>> >> As tiny as the mods now are to support more extensive ipv6 in openwrt,
>> >> that certainly was not the case in 2012.
>> >>
>> >> >
>> >> > -- Juliusz
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> Dave Täht
>> Open Networking needs **Open Source Hardware**
>>
>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>



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

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

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

[Dave Taht]

About to go try disabling the shaper here...

But I might argue for getting best results you should add buttons for

fiber cable dsl
wifi   wifi    wifi

Because wifi itself is so jittery, and it would be good to distinguish
ethernet results from wifi ones in your db.

On Wed, Apr 29, 2015 at 9:43 PM, Dave Taht <dave.taht@gmail.com> wrote:
> A: (fq_codel no ecn) (http://www.dslreports.com/speedtest/393466
>
> A+ (fq_codel + ecn was enabled) http://www.dslreports.com/speedtest/393300
>
> A: (fq_codel) http://www.dslreports.com/speedtest/393241
>
> A: (fq_codel) http://www.dslreports.com/speedtest/391178
>
> D: (fq_codel on the link but over wifi)
> http://www.dslreports.com/speedtest/391178
>
> Lemme go check native comcast and pie....
>
>
> On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
>> yes it did get no rating, I don't generate ratings unless everything looks
>> "right",
>> meaning a decent number of down idle and up pings.
>>
>> http://www.dslreports.com/speedtest/377563
>>
>> There are only 6 latency samples during download, even though the download
>> phase started at the 12 second mark and continued until the 23 second mark,
>> (meaning 11 seconds).
>>
>> The latency pings that happened during the download got held up to the
>> extent
>> that they came in and were counted as "idle" ones. I'll have to ponder on
>> this,
>> I think my pings need to be labelled by origin (what we were doing when they
>> were sent) not classified as they return.
>>
>> if it did get a rating it would be an "D" or "F"..
>>
>>
>> On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>
>>> Heh. Anything above a 250ms gets a F from me. But I strongly approve
>>> of simplification to a set of grades.
>>>
>>> http://www.dslreports.com/speedtest/378980 F, for sure.
>>>
>>> Secondly, we tend to regard bufferbloat as one word not two.
>>>
>>> This result got no rating. http://www.dslreports.com/speedtest/377563
>>>
>>> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
>>> > I've added the discussed "bloat rating".
>>> >
>>> > It takes the idle period before download uses the lowest latency as a
>>> > baseline.
>>> > then it takes the median download and median of upload+trailing idle
>>> > time,
>>> > and
>>> > subtracts to get the latency increase, then converts to a grade.
>>> >
>>> > Based on a very few results I've looked at the Grade seems reasonable.
>>> > I've
>>> > added
>>> > a link below the grade for the WTF is this moment a lot of people will
>>> > have,
>>> > which
>>> > takes them to a short FAQ entry, and then a link to bufferbloat.net ..
>>> >
>>> >
>>> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>> >>
>>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
>>> >> <jch@pps.univ-paris-diderot.fr> wrote:
>>> >> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
>>> >> > been
>>> >> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
>>> >> > there's one thing that annoys me -- they have two distinct CPEs, the
>>> >> > classic FreeBox (which I have) and the FreeBox Revolution (which is
>>> >> > slightly less cheap, and takes more physical space -- a big deal if
>>> >> > you
>>> >> > live in Paris).  The classic FreeBox needs some love from the
>>> >> > firmware
>>> >> > developers, and I'd be curious to know whether your results apply
>>> >> > equally
>>> >> > to both boxen.
>>> >>
>>> >> All ya gotta do is run the new dslreports and/or rrul test(s) on your
>>> >> own older box, and post. ;)
>>> >>
>>> >> My understanding was that the old freebox was too weak to run anything
>>> >> but SFQ, but it did run that on the outbound.
>>> >>
>>> >> >
>>> >> > (The thing that most pisses me off with the classic FreeBox is that
>>> >> > it
>>> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
>>> >> > Revolution,
>>> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
>>> >>
>>> >> As tiny as the mods now are to support more extensive ipv6 in openwrt,
>>> >> that certainly was not the case in 2012.
>>> >>
>>> >> >
>>> >> > -- Juliusz
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> 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
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Dave Täht
>>> Open Networking needs **Open Source Hardware**
>>>
>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>>
>>
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67



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

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

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

[Dave Taht]

1) From an OSX box over ethernet to the router.

Normal comcast blast service with no shaping:

F: http://www.dslreports.com/speedtest/394057

2) fq_codel with ECN enabled. Puzzled as to why this would not be an A+

A: http://www.dslreports.com/speedtest/394059

qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300
target 5.0ms interval 100.0ms ecn
 Sent 16656658 bytes 29867 pkt (dropped 408, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1514 drop_overlimit 0 new_flow_count 11758 ecn_mark 9609
  new_flows_len 1 old_flows_len 5

3) fq_codel, no ECN

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

qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300
target 5.0ms interval 100.0ms
 Sent 22610612 bytes 54551 pkt (dropped 1454, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  maxpacket 1514 drop_overlimit 0 new_flow_count 24747 ecn_mark 0
  new_flows_len 1 old_flows_len 3

(for anyone puzzled as to why there are so many ecn marks compared to
drops in these two, I have continually made the point that dropping
clears the congestion immediately, (particularly with IW stuff) - but
it is ok to mark a lot so long as it is ultimately effective within
multiple RTTs.

4) pie with ecn gets an A, where I would give it a B at best.

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

qdisc pie 120: parent 1:12 limit 1001p target 5.0ms tupdate 30.0ms
alpha 2 beta 20 ecn
 Sent 21363840 bytes 42994 pkt (dropped 1478, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 42994 overlimit 0 dropped 1478 maxq 82 ecn_mark 96

5) Linux codel really struggles to get it down on inbound, getting a deserved C:

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

6) ns2_codel does mildly better, but still struggles with this workload

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

On Wed, Apr 29, 2015 at 9:55 PM, Dave Taht <dave.taht@gmail.com> wrote:
> About to go try disabling the shaper here...
>
> But I might argue for getting best results you should add buttons for
>
> fiber cable dsl
> wifi   wifi    wifi
>
> Because wifi itself is so jittery, and it would be good to distinguish
> ethernet results from wifi ones in your db.
>
> On Wed, Apr 29, 2015 at 9:43 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> A: (fq_codel no ecn) (http://www.dslreports.com/speedtest/393466
>>
>> A+ (fq_codel + ecn was enabled) http://www.dslreports.com/speedtest/393300
>>
>> A: (fq_codel) http://www.dslreports.com/speedtest/393241
>>
>> A: (fq_codel) http://www.dslreports.com/speedtest/391178
>>
>> D: (fq_codel on the link but over wifi)
>> http://www.dslreports.com/speedtest/391178
>>
>> Lemme go check native comcast and pie....
>>
>>
>> On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
>>> yes it did get no rating, I don't generate ratings unless everything looks
>>> "right",
>>> meaning a decent number of down idle and up pings.
>>>
>>> http://www.dslreports.com/speedtest/377563
>>>
>>> There are only 6 latency samples during download, even though the download
>>> phase started at the 12 second mark and continued until the 23 second mark,
>>> (meaning 11 seconds).
>>>
>>> The latency pings that happened during the download got held up to the
>>> extent
>>> that they came in and were counted as "idle" ones. I'll have to ponder on
>>> this,
>>> I think my pings need to be labelled by origin (what we were doing when they
>>> were sent) not classified as they return.
>>>
>>> if it did get a rating it would be an "D" or "F"..
>>>
>>>
>>> On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>
>>>> Heh. Anything above a 250ms gets a F from me. But I strongly approve
>>>> of simplification to a set of grades.
>>>>
>>>> http://www.dslreports.com/speedtest/378980 F, for sure.
>>>>
>>>> Secondly, we tend to regard bufferbloat as one word not two.
>>>>
>>>> This result got no rating. http://www.dslreports.com/speedtest/377563
>>>>
>>>> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
>>>> > I've added the discussed "bloat rating".
>>>> >
>>>> > It takes the idle period before download uses the lowest latency as a
>>>> > baseline.
>>>> > then it takes the median download and median of upload+trailing idle
>>>> > time,
>>>> > and
>>>> > subtracts to get the latency increase, then converts to a grade.
>>>> >
>>>> > Based on a very few results I've looked at the Grade seems reasonable.
>>>> > I've
>>>> > added
>>>> > a link below the grade for the WTF is this moment a lot of people will
>>>> > have,
>>>> > which
>>>> > takes them to a short FAQ entry, and then a link to bufferbloat.net ..
>>>> >
>>>> >
>>>> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>>> >>
>>>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
>>>> >> <jch@pps.univ-paris-diderot.fr> wrote:
>>>> >> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
>>>> >> > been
>>>> >> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
>>>> >> > there's one thing that annoys me -- they have two distinct CPEs, the
>>>> >> > classic FreeBox (which I have) and the FreeBox Revolution (which is
>>>> >> > slightly less cheap, and takes more physical space -- a big deal if
>>>> >> > you
>>>> >> > live in Paris).  The classic FreeBox needs some love from the
>>>> >> > firmware
>>>> >> > developers, and I'd be curious to know whether your results apply
>>>> >> > equally
>>>> >> > to both boxen.
>>>> >>
>>>> >> All ya gotta do is run the new dslreports and/or rrul test(s) on your
>>>> >> own older box, and post. ;)
>>>> >>
>>>> >> My understanding was that the old freebox was too weak to run anything
>>>> >> but SFQ, but it did run that on the outbound.
>>>> >>
>>>> >> >
>>>> >> > (The thing that most pisses me off with the classic FreeBox is that
>>>> >> > it
>>>> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
>>>> >> > Revolution,
>>>> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
>>>> >>
>>>> >> As tiny as the mods now are to support more extensive ipv6 in openwrt,
>>>> >> that certainly was not the case in 2012.
>>>> >>
>>>> >> >
>>>> >> > -- Juliusz
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> 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
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Dave Täht
>>>> Open Networking needs **Open Source Hardware**
>>>>
>>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>>>
>>>
>>
>>
>>
>> --
>> Dave Täht
>> Open Networking needs **Open Source Hardware**
>>
>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67



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

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

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

[jb]

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

> 2) fq_codel with ECN enabled. Puzzled as to why this would not be an A+

Hah blame your own standards :)

The idle minimum was 66ms
The median down was +4.5ms higher
The median up was +5.5ms higher

the average of 4,5 and 5.5 is 5.0 which puts it as an "A"
but if it was a <= rather than a < it might have been an A+

Can't go handing out A+ like candy.
(happy to change this, if you think it is unrealistically tough, for
example, average
of idle vs median of up/down). I wanted to avoid outliers upsetting things.

On Thu, Apr 30, 2015 at 3:23 PM, Dave Taht <dave.taht@gmail.com> wrote:

> 1) From an OSX box over ethernet to the router.
>
> Normal comcast blast service with no shaping:
>
> F: http://www.dslreports.com/speedtest/394057
>
> 2) fq_codel with ECN enabled. Puzzled as to why this would not be an A+
>
> A: http://www.dslreports.com/speedtest/394059
>
> qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300
> target 5.0ms interval 100.0ms ecn
>  Sent 16656658 bytes 29867 pkt (dropped 408, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 1514 drop_overlimit 0 new_flow_count 11758 ecn_mark 9609
>   new_flows_len 1 old_flows_len 5
>
> 3) fq_codel, no ECN
>
> http://www.dslreports.com/speedtest/394097
>
> qdisc fq_codel 120: parent 1:12 limit 1001p flows 1024 quantum 300
> target 5.0ms interval 100.0ms
>  Sent 22610612 bytes 54551 pkt (dropped 1454, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
>   maxpacket 1514 drop_overlimit 0 new_flow_count 24747 ecn_mark 0
>   new_flows_len 1 old_flows_len 3
>
> (for anyone puzzled as to why there are so many ecn marks compared to
> drops in these two, I have continually made the point that dropping
> clears the congestion immediately, (particularly with IW stuff) - but
> it is ok to mark a lot so long as it is ultimately effective within
> multiple RTTs.
>
> 4) pie with ecn gets an A, where I would give it a B at best.
>
> http://www.dslreports.com/speedtest/394114
>
> qdisc pie 120: parent 1:12 limit 1001p target 5.0ms tupdate 30.0ms
> alpha 2 beta 20 ecn
>  Sent 21363840 bytes 42994 pkt (dropped 1478, overlimits 0 requeues 0)
>  backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 42994 overlimit 0 dropped 1478 maxq 82 ecn_mark 96
>
> 5) Linux codel really struggles to get it down on inbound, getting a
> deserved C:
>
> http://www.dslreports.com/speedtest/394129
>
> 6) ns2_codel does mildly better, but still struggles with this workload
>
> http://www.dslreports.com/speedtest/394138
>
> On Wed, Apr 29, 2015 at 9:55 PM, Dave Taht <dave.taht@gmail.com> wrote:
> > About to go try disabling the shaper here...
> >
> > But I might argue for getting best results you should add buttons for
> >
> > fiber cable dsl
> > wifi   wifi    wifi
> >
> > Because wifi itself is so jittery, and it would be good to distinguish
> > ethernet results from wifi ones in your db.
> >
> > On Wed, Apr 29, 2015 at 9:43 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >> A: (fq_codel no ecn) (http://www.dslreports.com/speedtest/393466
> >>
> >> A+ (fq_codel + ecn was enabled)
> http://www.dslreports.com/speedtest/393300
> >>
> >> A: (fq_codel) http://www.dslreports.com/speedtest/393241
> >>
> >> A: (fq_codel) http://www.dslreports.com/speedtest/391178
> >>
> >> D: (fq_codel on the link but over wifi)
> >> http://www.dslreports.com/speedtest/391178
> >>
> >> Lemme go check native comcast and pie....
> >>
> >>
> >> On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
> >>> yes it did get no rating, I don't generate ratings unless everything
> looks
> >>> "right",
> >>> meaning a decent number of down idle and up pings.
> >>>
> >>> http://www.dslreports.com/speedtest/377563
> >>>
> >>> There are only 6 latency samples during download, even though the
> download
> >>> phase started at the 12 second mark and continued until the 23 second
> mark,
> >>> (meaning 11 seconds).
> >>>
> >>> The latency pings that happened during the download got held up to the
> >>> extent
> >>> that they came in and were counted as "idle" ones. I'll have to ponder
> on
> >>> this,
> >>> I think my pings need to be labelled by origin (what we were doing
> when they
> >>> were sent) not classified as they return.
> >>>
> >>> if it did get a rating it would be an "D" or "F"..
> >>>
> >>>
> >>> On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com>
> wrote:
> >>>>
> >>>> Heh. Anything above a 250ms gets a F from me. But I strongly approve
> >>>> of simplification to a set of grades.
> >>>>
> >>>> http://www.dslreports.com/speedtest/378980 F, for sure.
> >>>>
> >>>> Secondly, we tend to regard bufferbloat as one word not two.
> >>>>
> >>>> This result got no rating. http://www.dslreports.com/speedtest/377563
> >>>>
> >>>> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
> >>>> > I've added the discussed "bloat rating".
> >>>> >
> >>>> > It takes the idle period before download uses the lowest latency as
> a
> >>>> > baseline.
> >>>> > then it takes the median download and median of upload+trailing idle
> >>>> > time,
> >>>> > and
> >>>> > subtracts to get the latency increase, then converts to a grade.
> >>>> >
> >>>> > Based on a very few results I've looked at the Grade seems
> reasonable.
> >>>> > I've
> >>>> > added
> >>>> > a link below the grade for the WTF is this moment a lot of people
> will
> >>>> > have,
> >>>> > which
> >>>> > takes them to a short FAQ entry, and then a link to bufferbloat.net
> ..
> >>>> >
> >>>> >
> >>>> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com>
> wrote:
> >>>> >>
> >>>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
> >>>> >> <jch@pps.univ-paris-diderot.fr> wrote:
> >>>> >> > Free.fr (Proxad) is certainly much better than other ISPs --
> they've
> >>>> >> > been
> >>>> >> > the first to give sort-of-native (6rd) IPv6 to the masses.
> However,
> >>>> >> > there's one thing that annoys me -- they have two distinct CPEs,
> the
> >>>> >> > classic FreeBox (which I have) and the FreeBox Revolution (which
> is
> >>>> >> > slightly less cheap, and takes more physical space -- a big deal
> if
> >>>> >> > you
> >>>> >> > live in Paris).  The classic FreeBox needs some love from the
> >>>> >> > firmware
> >>>> >> > developers, and I'd be curious to know whether your results apply
> >>>> >> > equally
> >>>> >> > to both boxen.
> >>>> >>
> >>>> >> All ya gotta do is run the new dslreports and/or rrul test(s) on
> your
> >>>> >> own older box, and post. ;)
> >>>> >>
> >>>> >> My understanding was that the old freebox was too weak to run
> anything
> >>>> >> but SFQ, but it did run that on the outbound.
> >>>> >>
> >>>> >> >
> >>>> >> > (The thing that most pisses me off with the classic FreeBox is
> that
> >>>> >> > it
> >>>> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
> >>>> >> > Revolution,
> >>>> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
> >>>> >>
> >>>> >> As tiny as the mods now are to support more extensive ipv6 in
> openwrt,
> >>>> >> that certainly was not the case in 2012.
> >>>> >>
> >>>> >> >
> >>>> >> > -- Juliusz
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> 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
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Dave Täht
> >>>> Open Networking needs **Open Source Hardware**
> >>>>
> >>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Dave Täht
> >> Open Networking needs **Open Source Hardware**
> >>
> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
> >
> >
> >
> > --
> > Dave Täht
> > Open Networking needs **Open Source Hardware**
> >
> > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>

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

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

[Dave Taht]

On Wed, Apr 29, 2015 at 9:33 PM, jb <justin@dslr.net> wrote:
> yes it did get no rating, I don't generate ratings unless everything looks
> "right",
> meaning a decent number of down idle and up pings.
>
> http://www.dslreports.com/speedtest/377563
>
> There are only 6 latency samples during download, even though the download
> phase started at the 12 second mark and continued until the 23 second mark,
> (meaning 11 seconds).
>
> The latency pings that happened during the download got held up to the
> extent
> that they came in and were counted as "idle" ones. I'll have to ponder on
> this,
> I think my pings need to be labelled by origin (what we were doing when they
> were sent) not classified as they return.

That seems good.

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

>
>
> On Thu, Apr 30, 2015 at 2:23 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Heh. Anything above a 250ms gets a F from me. But I strongly approve
>> of simplification to a set of grades.
>>
>> http://www.dslreports.com/speedtest/378980 F, for sure.
>>
>> Secondly, we tend to regard bufferbloat as one word not two.
>>
>> This result got no rating. http://www.dslreports.com/speedtest/377563
>>
>> On Wed, Apr 29, 2015 at 9:07 PM, jb <justinbeech@gmail.com> wrote:
>> > I've added the discussed "bloat rating".
>> >
>> > It takes the idle period before download uses the lowest latency as a
>> > baseline.
>> > then it takes the median download and median of upload+trailing idle
>> > time,
>> > and
>> > subtracts to get the latency increase, then converts to a grade.
>> >
>> > Based on a very few results I've looked at the Grade seems reasonable.
>> > I've
>> > added
>> > a link below the grade for the WTF is this moment a lot of people will
>> > have,
>> > which
>> > takes them to a short FAQ entry, and then a link to bufferbloat.net ..
>> >
>> >
>> > On Thu, Apr 30, 2015 at 4:32 AM, Dave Taht <dave.taht@gmail.com> wrote:
>> >>
>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
>> >> <jch@pps.univ-paris-diderot.fr> wrote:
>> >> > Free.fr (Proxad) is certainly much better than other ISPs -- they've
>> >> > been
>> >> > the first to give sort-of-native (6rd) IPv6 to the masses.  However,
>> >> > there's one thing that annoys me -- they have two distinct CPEs, the
>> >> > classic FreeBox (which I have) and the FreeBox Revolution (which is
>> >> > slightly less cheap, and takes more physical space -- a big deal if
>> >> > you
>> >> > live in Paris).  The classic FreeBox needs some love from the
>> >> > firmware
>> >> > developers, and I'd be curious to know whether your results apply
>> >> > equally
>> >> > to both boxen.
>> >>
>> >> All ya gotta do is run the new dslreports and/or rrul test(s) on your
>> >> own older box, and post. ;)
>> >>
>> >> My understanding was that the old freebox was too weak to run anything
>> >> but SFQ, but it did run that on the outbound.
>> >>
>> >> >
>> >> > (The thing that most pisses me off with the classic FreeBox is that
>> >> > it
>> >> > doesn't allow IPv6 subnetting -- unless you order the FreeBox
>> >> > Revolution,
>> >> > you're condemned to the purgatory of ND-proxying.  Grr.)
>> >>
>> >> As tiny as the mods now are to support more extensive ipv6 in openwrt,
>> >> that certainly was not the case in 2012.
>> >>
>> >> >
>> >> > -- Juliusz
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> Dave Täht
>> Open Networking needs **Open Source Hardware**
>>
>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>



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

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

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

[Rich Brown]

> 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

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

[jb]

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

Already users are like "how can i fix this!".

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.

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

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

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

[Bloat] ThinkBroadBand also has a bloat detector in their speed test

[Rich Brown]

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

I just saw a note over at ThinkBroadBand that states that they've turned on bufferbloat detection/grades in their speed test. 

Announcement: http://forums.thinkbroadband.com/general/t/4405918-turned-on-per-user-display-now.html
The Tester: http://www.thinkbroadband.com/speedtest.html

I'm not sure it gives as good a result as DSLReports Speed Test.

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

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

[Dave Taht]

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

Re: [Bloat] ThinkBroadBand also has a bloat detector in their speed test

[jb]

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

It gives my connection an "A" in both directions :)
Which would be incorrect as it is a definite "D" or worse.

But it is hosted in the UK, and uses a single stream, so it doesn't fill
the pipe.
If it can't fill an 8mbit connection it is going to be misleading  - unless
you are very close to them.

On Fri, May 1, 2015 at 2:41 PM, Rich Brown <richb.hanover@gmail.com> wrote:

> I just saw a note over at ThinkBroadBand that states that they've turned
> on bufferbloat detection/grades in their speed test.
>
> Announcement:
> http://forums.thinkbroadband.com/general/t/4405918-turned-on-per-user-display-now.html
> The Tester: http://www.thinkbroadband.com/speedtest.html
>
> I'm not sure it gives as good a result as DSLReports Speed Test.
>

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

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

[jb]

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

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

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

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

[Dave Taht]

On Thu, Apr 30, 2015 at 11:31 PM, 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..

98th percentile across the cdf? (It would be interesting to calculate
this across your data set thus far, regardless)

Use two measurements  - one of jitter one of median latency increase?

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

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



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

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

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

[Sebastian Moeller]

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

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

[jb]

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

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

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.

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

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

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

[Sebastian Moeller]

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

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

[Dave Taht]

1 probe per second IZ not enough for science! (see my forked thread)

On Sat, May 2, 2015 at 8:01 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> 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
>>
>>
>
> _______________________________________________
> 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] extremely good dslreports result for bufferbloat on free.fr

[Aaron Wood]

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

On Thu, Apr 30, 2015 at 8:10 PM, jb <justin@dslr.net> wrote:

> Already users are like "how can i fix this!".
>
> 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've got the same modem, and it's latency is "not horrible" in the face of
good bandwidth (120 down/ 12 up), but this confirms my suspicion that it is
a case of the higher rates result in less overall buffering time in the
modem.

-Aaron

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