Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] Perfection vs. Good Enough
Date: Sun, 12 Jan 2014 16:10:17 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.02.1401121603400.6616@nftneq.ynat.uz> (raw)
In-Reply-To: <9EA0DCA1-79CF-48EF-9864-A51807F331B5@gmx.de>

On Sat, 11 Jan 2014, Sebastian Moeller wrote:

>>> Compared to the orders of magnitude we already get from fq codel, the sum benefit
>>> of these [Link Layer Adaptation] fixes is in the very small percentage points.
>
> 	I do not agree with this sentiment, as I understood Dave was talking 
> about different modifications to fq_codel (nfq_codel and efq_codel), this was 
> not about the link layer; for an ATM link if you get the link layer wrong the 
> shaper does at best work stochastically; and if the shaper does not work well 
> we are back at square one: badly managed buffers out of our control filling up 
> causing delays worth seconds. So unless you shape down to ~50% of link rate, 
> you will get at least temporary buffer bloat on an ATM link, unless you take 
> all the ATM peculiarities into account (basically what link layer ATM is 
> doing).

the question boils down to

compared to stock firmware,

how much of a beneifit is openwrt trunk (and how risky)
how much of a benefit is cerowrt without the link-level tuning

how much additional benefit do we expect to get from the added work.

What we have now is a huge step forward compared to stock firmware, a 
significant portion of this benefit has been pushed upstream to openwrt.

but right now there is a lot of work to make things perfect, and as a result, 
people are stuck using stock firmware or openwrt releases (unless they compile 
their own image from trunk), and so they are missing everything that's been 
done.

There is a lot of value in getting another release out that brings all the gains 
that we have now to everyone. Then development can continue trying to optimize 
things more.

David Lang

  parent reply	other threads:[~2014-01-13  0:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-11 16:31 Rich Brown
2014-01-11 18:08 ` Theodore Ts'o
2014-01-11 18:30 ` Sebastian Moeller
2014-01-11 18:47   ` Rich Brown
2014-01-11 20:03     ` Sebastian Moeller
2014-01-13  0:10   ` David Lang [this message]
2014-01-13  3:14     ` Theodore Ts'o
2014-01-13  3:49       ` Michael Richardson
2014-01-13  0:02 ` David Lang

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/cerowrt-devel.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1401121603400.6616@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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