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
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
