[Cerowrt-devel] Where we're winning

[Cerowrt-devel] Where we're winning

[Dave Taht]

All:

I am incredibly open to suggestions as to how to make cerowrt less
of a success disaster.

First up on my list was to try and communicate
better about the state of the project. This includes things like
activating the cerowrt-commits mailing list, and starting this one.

Where we are winning:

1) Stability - no final release candidate has EVER crashed. So far as
I know none of the smoketests later than say, a '4', has ever crashed,
either. This is an amazing tribute to the linux and openwrt development
process, and (in some small part) the degree of testing that I do.

2) Press. With cringley and lwn.net and slashdot, we have
got nothing but rave reviews and encouragement for what we're
trying to do.

3) We have incredible amounts of verbal support from heavyweights
in the industry, starting wtih jim gettys of course. The expressions of
support and interest from tons of people that I admire deeply keep
me going...

4) Openwrt itself has improved dramatically - 99.9% of this would have
happened without our feedback, frankly - but it has been amazing to
watch the quality of its tools, device drivers, kernel, and packages
improve on what seems to be a daily basis. Recently, I took
a look at the gui from back in june to where it is now, and *wow*.

5) As a research tool, Cerowrt has been utterly invaluable (to me at least)
for understanding the current (mis)behavior of wireless, the
interrelationships of the stack and drivers and packet scheduler, and
for getting a good grip on what is actually possible to achieve on
a modern consumer-grade device.

At this point I'm utterly certain that

A) it is possible to implement very complex queue management and
thus, begin to beat bufferbloat at the network edge, where it bothers
people the most.

B) it is possible to improve wired and wireless behavior enormously

C) it is possible to implement advanced functionality like dnssec and
windows services

D) it is possible to get ipv6 working, routing working, local web and
DNS services working, and a whole lot more

In summary, it IS possible to build a device far superior to anything
shipped today, one that can set an example for the rest of the industry,
save everyone time, and hassle, and do it for very low cost, AND
consisting almost purely of software that can be applied to any
hardware with the same capabilities, thus introducing competition
to drive the costs down while holding the desirable feature set
to a whole new standard.

and we didn't know any of that when we started.

I am very encouraged by the progress we've made
towards understanding and defeating bufferbloat over the past year.

However, the last several months of this project have
had some problems that have really been holding back
progress, and I'll get to talking about the negatives in a day
or two.

In the meantime, if you have any thoughts towards where we
can go with this project in the coming year that will have the
most  impact on improving the state of things at the Internet edge,
please share them here.

"Ask not what cerowrt can do for you, but what you can do
 for cerowrt!"

Where else are we winning? What else can do better?


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

Re: [Cerowrt-devel] Where we're winning

[david]

On Sun, 4 Dec 2011, Dave Taht wrote:

> All:
>
> I am incredibly open to suggestions as to how to make cerowrt less
> of a success disaster.

I think one key thing to do is to step back and think about what the 
definition of 'stable' vs 'rc' mean

the purpose of cerowrt is to put new stuff out for people to experiment 
with. by defintition, this means that you don't know for sure what the 
results of things will be, so by the time you figure it out to create a 
'stable' release, the result is not going to be anything that you care 
about because it is now standard.

I think you need to accept that there is going to be some amount of 
experimental stuff that may break.

I think the key requirement is that it needs to be easy to turn off the 
experimental stuff to go back to the default upstream behavior if it 
doesn't work for someone.

At that point, it should not be a -rc release as it's ready for people to 
really use.



there appear to be three parts to cerowrt.

1. picking useful tools from openwrt to include by default

2. modifying specific packages to introduce new features.

3. modify default values

I'm wondering if the right thing to do isn't to stop trying to ship a 
complete firmware, but instead ship packages to be put on a standard 
openwrt distro.

thinking about this. I see the value breaking down along the following 
lines


1. picking useful tools to include by default

I don't see a lot of value in shipping a distro to do this. have a page 
somewhere listing the packages (possibly even with cut-n-past installation 
lines)

2. modifying specific packages

with the exception of the kernel (which needs to be device specific), you 
should be able to make modified versions of any packages to be downloaded 
and installed very muchlike #1

for the kernel, I don't know what it takes with openwrt to install a new 
kernel (is it a complete reinstall of everything? or is there a way to 
have two kernels and switch between them?)

3. modifying config options

can this be done either through cut-n-past instructions or via a package 
to install?


with the extent of these changes, people would need to install the 
squashfs version instead of the jff2 version.


by doing these things as modifications/instructions rather than a packaged 
distro release, you don't lock yourself down to a single hardware 
platform. It will require more knowledge on the part of the people using 
it, but I don't think that the people without this knowledge will be 
willing to run -rc versions.

This would also make it easier to answer questions like I asked a couple 
weeks ago about what parts are ready for production use and what are 
really experimental.

thoughts?

David Lang

Re: [Cerowrt-devel] Where we're winning

[Dave Taht]

I'm going to step back and simply listen for a while

On Sun, Dec 4, 2011 at 10:27 PM,  <david@lang.hm> wrote:
> On Sun, 4 Dec 2011, Dave Taht wrote:
>
>> All:
>>
>> I am incredibly open to suggestions as to how to make cerowrt less
>> of a success disaster.
>

I'm going to step back and simply listen for a while, and
solicit opinions from as many other stakeholders as possible,
this week.

We did a lot with this in the last 9 months, I'd like us to stretch
our minds out to extend as to what can - and more importantly
should - be done - with this sub-project of bufferbloat.net's,
over the next year.

I value your input below very much and really want to conduct
a brainstorming session here, so I'm not going to venture
an opinion for a while. I MIGHT stir the pot a little bit here
and there.... ;)

> I think one key thing to do is to step back and think about what the
> definition of 'stable' vs 'rc' mean

But, yes, I think the rc and the rc-smoketest concept is not working
out.

As for the rest of your thoughts, I really want input from lots
of people! this week. So forgive me for not commenting further.
I hope more people jump in.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

Re: [Cerowrt-devel] Where we're winning

[Dave Taht]

Despite my attempt to step back, I can't help but also comment on this
last bit:

> This would also make it easier to answer questions like I asked a couple
> weeks ago about what parts are ready for production use and what are really
> experimental.

Your question here is very profound, and I'd like more to think upon
and expound upon it.

How do we get from experimental to production better than we have?

What processes/people/ideas can we put in place to shorten the distance
between experiment and deployment? For that matter, what experiments
are worthwhile to conduct and how can we reasonably determine the quality
of the results?

>
> thoughts?
>
> David Lang
>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net