General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: jb <justin@dslr.net>
To: Dave Taht <dave.taht@gmail.com>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] extremely good dslreports result for bufferbloat on free.fr
Date: Thu, 30 Apr 2015 15:49:53 +1000	[thread overview]
Message-ID: <CAH3Ss95tL1nw=OPVfuJoNmMuWOeYWVpH7cULsfxNaS01p8NgAA@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw7=KmcGtkTPLkW3fSJSR77O9V0V+p2sqhUdVrpQ8UCPjQ@mail.gmail.com>

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

  reply	other threads:[~2015-04-30  5:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 14:48 Dave Taht
2015-04-28 23:33 ` jb
2015-04-28 23:44   ` David Lang
2015-04-29  1:39     ` Jonathan Morton
2015-04-29  2:01       ` Dave Taht
2015-04-29  2:49       ` jb
2015-04-29 16:32 ` Juliusz Chroboczek
2015-04-29 18:32   ` Dave Taht
     [not found]     ` <CAH3Ss96FnwgK8qxdV-n46GLe2FSsRRa7zD1M_Wmq91o=+-7qdQ@mail.gmail.com>
2015-04-30  4:23       ` Dave Taht
2015-04-30  4:33         ` jb
2015-04-30  4:43           ` Dave Taht
2015-04-30  4:55             ` Dave Taht
2015-04-30  5:23               ` Dave Taht
2015-04-30  5:49                 ` jb [this message]
2015-04-30 16:36           ` Dave Taht
2015-05-01  0:48             ` Rich Brown
2015-05-01  3:10               ` jb
2015-05-01  4:41                 ` [Bloat] ThinkBroadBand also has a bloat detector in their speed test Rich Brown
2015-05-01  6:17                   ` jb
2015-05-01  6:05                 ` [Bloat] extremely good dslreports result for bufferbloat on free.fr Dave Taht
2015-05-01  6:31                   ` jb
2015-05-01  8:10                     ` Dave Taht
2015-05-02 11:49                     ` Sebastian Moeller
2015-05-02 13:40                       ` jb
2015-05-02 15:01                         ` Sebastian Moeller
2015-05-02 16:55                           ` Dave Taht
2015-05-02 17:15                 ` Aaron Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH3Ss95tL1nw=OPVfuJoNmMuWOeYWVpH7cULsfxNaS01p8NgAA@mail.gmail.com' \
    --to=justin@dslr.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox