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