[Bloat] an update on cerowrt-rc7

[David Täht]

On 10/27/2011 02:40 PM, Riccardo Giuntoli wrote:
> What about consider to give a version to people that want to try 
> cerowrt on other atheros based platforms?
>

While it is easy to build for multiple platforms, it is impossible to 
test on more than a very few. Secondly there are currently hard coded 
differences in the filesystem(s) and device sets that make getting 
initial filesystems 'perfect' a difficult, tedious process. Fixing the 
first would be easy. The second, less so.

Merely having a difference between the 3700 and the 3700v2 has confused 
many users!

Earlier on in cerowrt we planned on doing the ubiquity nanostation M5 
(long distance wifi tests) and the dreamplug, and a kvm, and a usb stick 
based version... basically anything that met our requirements of at 
least 64MB ram and 16+MB flash.

All of which we did do at one point or another, and the net result was 
that the testing cycle took so long as to dominate the actual effort 
involved in doing anything else!

and we're trying to fix bufferbloat here, with a rapid 
compile/test/debug cycle designed to stay within the kernel development 
window. I'm happy we're staying in that window, very unhappy with the 
amount of effort required to do just that much.

But:

It should be very easy to adapt the existing cerowrt build process to 
attempt a build of your own for whatever hardware you might like -

http://www.bufferbloat.net/projects/cerowrt/wiki/Building_Cerowrt_on_your_own_machine

All you really have to do after that is a 'make menuconfig' and select 
different hardware than the default, keeping in mind that the filesystem 
is designed for a dual channel radio and non-bridged ethernet devices 
and > 8MB of flash is required...

I can EASILY do builds for all the ar7100 based hardware, but I don't 
know which of the several dozen boards supported in the build system 
meet the above requirements. I was thinking of adding routerstation pro 
support in a a future build and maybe a d-link...

And:

Patches gladly accepted as always.


> Like all the http://routerboard.com ones?
>
There are multiple issues with this idea.

Most importantly: Dave does not scale.  (see above)

Secondly, microtik ships a (very user friendly, IMHO) version of an 
integrated router distro on their own, called RouterOS.  It's high on my 
list to poke into RouterOS, (does bufferbloat truly live EVERYWHERE??) 
but I have a very, very, very long list... I would appreciate someone 
(else!) taking a look at what they do to alleviate the bloat, reporting 
back on what kernel they use, how good is there ipv6 support, what size 
buffering they use, what they are doing for QoS/AQM etc.

Or better, someone from microtik participating on the list!

... as it's my hope that talking about the issue of bufferbloat 
coherently, often, and in public is best - and cerowrt and 
debloat-testing's model of figuring out problems, testing/fixing them, 
and pushing them upstream to kernel head/openwrt head/package head means 
that everybody wins and we don't have to look all that much at other 
distros.

Speaking of that, I've been lax of late in pushing some stuff upstream...

PS I would VERY MUCH like to get out of cerowrt's current wifi 
monoculture however and get a good grasp of other wifi chip designs, 
before even thinking about an debloating api for wireless-n - I am glad 
that broadcom and iwl are now mostly open, only marvel is lagging on that...

(I do like atheros's architecture, however. the iwl cards scare me)

So at some point after cero gets more stable I'm going to go start 
hacking on debloat-testing again.

PPS cerowrt rc7-smoketest7 is out and working pretty good!

-- 
Dave Täht

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dave_taht.vcf
Type: text/x-vcard
Size: 204 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20111031/8a1015a8/attachment-0002.vcf>