[Cerowrt-devel] notes on going for a stable release

[Dave Taht]

On Tue, Jan 14, 2014 at 3:37 AM, Christopher Robin <pheoni at gmail.com> wrote:
> Thanks for these notes. As a user who's been frustrated in trying to
> understand the state of CeroWrt and find a way to contribute, I find
> this very helpful. I'm not sure what to make of the following though.

Welcome aboard! You might get a better feel for the development via
visiting the #bufferbloat channel on freenode, although of late I've
not been there. I will reform.

>
> On Tue, Jan 14, 2014 at 1:07 AM, Dave Taht <dave.taht at gmail.com> wrote:
>> ** What is CeroWrt?
>>
>> Originally intended to prove out a bunch of AQM and scheduling ideas,
>> it's done that. We proved dnssec was feasible, and simon kelly is
>> doing that. ISC and openwrt got signed updates working recently, the
>> only major update-in-the-field problem for openwrt is on updating
>> kernels.
>>
>> CeroWrt is ALSO useful for day-to-day use, presently.
>
>
> If CeroWrt has fulfilled it's original intentions, where does that
> leave us now?

Well, some core things are still WIP. I forgot to mention that
stuart cheshire is also working on adding this to mdnsresponder

http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01

which would let us either improve avahi or switch to
mdnsresponder.

> What improvements is CeroWrt currently working on that
> OpenWrt lacks?

At the moment "CeroWrt" isn't really working on much that
openwrt lacks, there are maybe 6 patches and a package
that haven't been pushed up yet. There is heavy development
on some core packages (like dnsmasq) going on that we've
been testing...

for example I don't think that nfq_codel or efq_codel will
ever make it up to openwrt, the benefits are too marginal.

>What's the end game?

Don't think there is an end game. :(

"Proving that 'stuff' can be done better on home routers".

> I haven't been here long, but it seems to me that CeroWrt should avoid
> being a distribution and instead stick to being a proof-of-concept
> project.

There have always been these two conflicting pulls. I LIKE the testing
we get from those that actually use it day to day, and the number of
cool people that do so is very scary.

> "Going stable" shouldn't mean having a release with bug fixes
> that's ready for a production environment, it should mean having the
> code tested to a point where it can be pushed upstream to OpenWrt to
> implement into their releases. It should be about setting a new "close
> enough" baseline to get testers/users to help stress test the new
> code.

Agree. So I don't want to use the word "stable", but something else.

> But I'm new here, and I don't fully understand the workflows and
> ideologies involved. Maybe having a stable release is required to push

If "doing correct science" is an ideology, then that's mine. Out of that falls
having full access to all source code.

> CeroWrt improvements upstream. Or maybe that's not what you guys are
> aiming for.

A month or so of testing and getting valid results is what I feel is needed
to get stuff upstream. I'm not happy with the results aaron has been getting,
and am thinking of reverting two patches in the upcoming 3.10.26-2

> Some questions that may help provide a better scope for the project:
>
> How many users have CeroWrt running in a production environment (as
> the primary router in a business)?

Don't know. More than 2.

> How many users have CeroWrt running as a primary or only router at home?

More than a few hundred.

> Is it a goal of this group to provide a CeroWrt build for businesses
> to run as their /only/ edge router on and expect 24/7 uptime?

Some versions of cero have been stable enough to stay up 9+ months.
This was one of my favorite bug reports EVER:

http://www.bufferbloat.net/issues/330

certainly in announcing a "stabler" release I'd like something that
stays up under heavy load for a month or more.

> Is it a goal of this group to provide a CeroWrt build easy enough for
> the average end user (grandma) to run on their only router?

Nope.

> ....
>
> Hrm, I'm rereading all the above and having difficulty liking it for
> some reason so let me sum up.
>
> ***Are we here for research and development, or are we here for final
> implementation?

R&D here.

I'm here mostly to prove out some new ideas in queue theory. I
do get a kick (everyone else here gets a kick, too, I think) out of battlng
cisco and the other big router vendors to their knees, and get them and
the ISPs to fix their darn equipment to work better with interactive
applications.

That process has been working out better and better over the past year.

I ALSO like having a router I can *trust* to be free of security flaws
- at least
as far as I and y'all can make it.

I also fiddle with mesh networking a bit. One of these days I'll have a
congestion aware routing metric that makes sense...

Everybody else has their own reasons.

> If we're here for R&D then our "stable" build should be what most
> distributions would consider as a beta. Something like we're 99%
> certain it won't brick your router and 80-95% certain it won't be
> unusable.
>
> If we're trying to be a distribution for end users, we should really
> look at expanding the number of routers we support.

I'd like to add some 802.11ac chipset, but *all the firmware*
needs to be available in source form.

The ath10k comes closest, but sadly all
of the new arm boards have got blobs for the ethernet drivers.

Currently. Many folk involved here have been campaigning
behind the scenes to get another blob-free router "out there",
and it feels like we are making progress.

maybe the new linksys product won't be a chimara, or mindspeed
will come through, or some other vendor will get a clue.


> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html