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

[Dave Taht <dave.taht@gmail.com>]

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