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

jb justin at dslr.net
Thu Apr 30 01:49:53 EDT 2015 

> 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>
> wrote:
> >>>> >>
> >>>> >> On Wed, Apr 29, 2015 at 9:32 AM, Juliusz Chroboczek
> >>>> >> <jch at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150430/e204d8e4/attachment-0003.html>

More information about the Bloat mailing list