[Cerowrt-devel] Perfection vs. Good Enough
Sebastian Moeller
moeller0 at gmx.de
Sat Jan 11 13:30:19 EST 2014
Hi Rich,
On Jan 11, 2014, at 17:31 , Rich Brown <richb.hanover at gmail.com> wrote:
> Folks,
>
> I am so pleased with the state of CeroWrt. The software has improved enormously, to the point that we all get really good performance from our routers at home. If you want a real eyeful of the progress we’ve made, check list at the bottom of the Release Notes: http://www.bufferbloat.net/projects/cerowrt/wiki/CeroWrt_310_Release_Notes
>
> CeroWrt is working great. We have two great testimonials for how it has improved network performance (from Fred Stratton and David Personnette, see https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-January/001961.html and https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-January/001970.html)
>
> I have been using 3.10.24-8 at home without hiccups (after I turned on SQM :-) since it was shipped. We’ve got a really great program.
>
> But - I’m afraid we’re letting perfection be the enemy of the good. Here are a couple indications:
>
> - The rest of the world doesn’t know about this good work. If you look at the front page of the site, we’re recommending CeroWrt 3.7.5-2 from last February. It has Codel, but not much more. Our understanding of the world has expanded by an order of magnitude, but we’re not making it available to anyone.
>
> - The entire discussion of link layers has held us back. That’s why I proposed to cut back the choices to ATM and None, and let people figure out the details if they want to/have time to optimize.
>
> - We have tons of updated modules (dnsmasq, IPv6, quagga, mosh) which we should get out to the world.
>
> - The entire product is much tighter, works better, and we can be proud of it. As Dave Täht pointed out in a recent note:
>
>> 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).
>
> This is true of the entire CeroWrt build.
>
> Proposal:
>
> We should “finish up the last bits” to make 3.10.24-8 (or a close derivative) be a stable release. It has been working fine AFAIK for lots and lots of us. It certainly has been as well tested as other branches. I see the following:
>
> - Look through the release notes (very bottom of the page at the URL above) and review the items that Dave was worried about for the 3.10.24-8 release
>
> - Make a decision on Link Layer Adaptation choices, and implement it.
It is quite clear to me, that I failed to explain the matters surrounding ATM links properly. But if I can not explain this to a small group of technical experts there is no chance for me to explain this to lay persons. I will try my best to contribute to the "more than you ever wanted to know about link layer adaptation" page.
Best Regards
Sebastian
>
> - What else?
>
> Best,
>
> Rich
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
More information about the Cerowrt-devel
mailing list