Re: [Cerowrt-devel] Perfection vs. Good Enough

[Sebastian Moeller <moeller0@gmx.de>]

Hi Rich,

On Jan 11, 2014, at 17:31 , Rich Brown <richb.hanover@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel