[Cerowrt-devel] keeping a better lab notebook, publishing results, etc?

Sat Jan 7 15:30:00 EST 2012

Thanks for the update. 

re: A better lab notebook... I don't have any suggestions for better tools for a lab notebook. But I have a few thoughts for combining your internal record-keeping with the publicly-facing pages. Please don't think I'm being whiny - I have a concrete suggestion at the end of all these comments:

- An important reason (the only reason?) to use any tool is so that you can be productive. You need the ability to record your important work/thoughts/plans. 

- You also need a tool to tell others how things are progressing. This is the public face to the project that draws interest/testers/excitement/participation.

- One reason to like Redmine is that it makes the project look professional and/or serious. I will confess that its appearance gave me the confidence to take a few minutes to look hard at the project. The documentation is good, correct, and substantially matches the current state of the code. 

- But..  the Bufferbloat pages for Cerowrt today also provide lots of unnecessary tabs/sections that absorb your brain cycles to keep up-to-date. I will also confess that I was a bit put off by the notes about RC7 & RC8 being delayed, and the deadlines that were missed. 

- Another problem with Redmine was that it took me a while to figure out which version I should consider.

- I looked at ikiwiki. Its presentation is pretty bare bones. Although it looks as if it could reflect your activities (whether on-line or not), I'm not sure it would be a good public face for the project. 

- I am pleased that you've put a lot of info into github.com. It makes it easy for us spectators to see when progress has been made.

- I would also like a way to know the fixes in progressive releases of Cerowrt. For example, I see that bql-15 is available. (NB It installs and operates just fine.) Is there a way to see the changes/release notes? 

- Finally, I know you're not looking for extra work, and certainly not documentation. A good solution has to minimize the amount of work you put into communicating the state of the project beyond what you would do anyway. For example:

- Notes in github, mailing lists: Good
- Time spent tweaking words in Redmine: Less good

And now my suggestion:

1) Continue to use Redmine. It's attractive, and there's a lot of good information is already there. Random visitors are familiar with its format and capabilities and will feel right at home.

2) Prune the Redmine site mercilessly. Remove anything that's no longer your current focus, or that distracts. After all, that's why you chose to cut out all the features that weren't going to happen anyway... For exaxmple, I would remove or minimize references to UberWRT, iSCWRT, Bismark, and other related projects unless you get a significant return from those projects. Redmine can then reflect a) things that are and will always be true about your current effort, and b) link to the info that's changing rapidly in other resources. (See my suggestions below).

3) Continue to use github to reflect useful test cases, thoughts, etc.

4) If you need for a personal notebook, pick your favorite. But find a way to get it into github from time to time so that we can read about it and so you're protected against failures.

5) You don't need to provide publicly-editable wiki-like facilities today. You and perhaps a couple others are driving the development, and Redmine site doesn't need to be burdened with the ability to support lots  of posters right now.

============= Suggestions for the Redmine site  ===============

Based on my understanding of your current goals, you might edit the Redmine site at http://www.bufferbloat.net/projects/cerowrt to say the following. (The information below would have answered the questions that I had about the project, and given me a good feeling about it right away. However, please feel free to ignore/adjust any of this...)

---- Overview tab -----

Overview:

Bufferbloat is a huge drag on Internet performance created, ironically, by previous attempts to make it work better. The one-sentence summary is "Bloated buffers lead to network-crippling latency spikes." You can read more about this problem at http://www.bufferbloat.net/projects/bloat/wiki/Introduction. [NB - this is a brilliant description of the problem -reb]

CeroWrt is a project built using OpenWrt to resolve these endemic problems in home networking today, and to push the state of the art of edge networks and routers forward. Projects include proper IPv6 support, tighter integration with DNSSEC, wireless mesh networking, among others, notably reducing bufferbloat in both the wired and wireless components of the stack.

To minimize the effects of hardware dependencies, we have chosen the Netgear WNDR3700v2 as the sole hardware for the experiments. The open source support for it is extensive, it has 16MB of flash and 64MB of RAM, it supports a USB flash stick, they are inexpensive (around $120).

Goals of the Cerowrt Project:

The next generation of cerowrt's feature set is currently being discussed on the Cerowrt-devel mailing list. At this stage, we are working to create a minimal, functioning build as a platform for experimentation.

Sources of Information about the project:

General list for discussing Bufferbloat: https://lists.bufferbloat.net/listinfo/bloat
Cerowrt-devel mailing list: https://lists.bufferbloat.net/listinfo/cerowrt-devel
Lab Notebook in Github: https://github.com/dtaht/deBloat

Installation Instructions:

The Cerowrt Installation Guide at http://www.bufferbloat.net/projects/cerowrt/wiki/OCEAN_CITY_INSTALLATION_GUIDE provides information for getting the software installed on the WNDF3700v2 and initial configuration.

Try the Software:

The current software is being used for experimentation on the algorithms. A few brave souls are also using it as a second router in their homes. At this stage, we do not recommend it as your production router.

The most recent builds are the "bql-smoketests". They are under active development.

The rc6 build is older, but in wider use. We have not received any reports of crashes so feel free to try in less experimental situations. 

You can retrieve either from the Files tab.

------- Activity tab -------

Not sure what you should go here. The info up to 29Dec2011 is good, but there is nothing about newer incremental builds. Should the ongoing narrative be transitioned to github or the mailing lists? If so, you need a link on this tab to point people there.

----- Roadmap tab -----

This needs the most pruning. Remove most (all?) of the text and replace with a brief description of where you expect to take things in the next month and three months (What you told me at the end of https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-January/000050.html might be a good start.)

--- Issues tab ---

Probably can remain, unless it's not really correct.

--- Gantt tab ---

Is there anything valuable here?

--- Calendar tab ---

Is there anything valuable here?

--- News tab ---

Remove anything that's more than 3 months old, or that's not relevant to the new goals.

The About Cerowrt section at the bottom may have something to retain, perhaps moving it to the Overview page. But many of the features listed have now been dropped from near-term consideration (IPv6, for example). 

Given that things are moving so rapidly, it makes sense that this page should refer people to the mailing lists or the lab notebooks, and not strive to be updated in parallel.

--- Documents tab ---

Again, this should reflect the project's current state. Jim Gettys' paper is good and should remain. I wonder if everything from the Wiki tab should be moved here.

Maybe a link to the Files tab as well. 

--- Wiki tab --- 

Maybe move all these links to the Documents page, then say "No wiki entries at this time. See the mailing lists and Lab Notebook".

--- Files tab ---

I feel an urge for a single page that provides a description of "stable" and "current" versions. It might say:

The current builds of Cerowrt are being used for experimentation on the algorithms to eliminate bufferbloat. Some brave souls are also using it as a second router in their homes. At this stage, we do not recommend it as your production router.

The most recent builds are the "bql-smoketests". They are available from http://huchra.bufferbloat.net/~cero1/bql-smoketests/ Use the openwrt-ar71xx-generic-wndr3700v2-squashfs-factory.img version. The Bufferbloat mailing list (https://lists.bufferbloat.net/listinfo/bloat) describes the changes for each version.

The rc6 build is older, but in wider use. We have not received any reports of crashes so feel free to try in less experimental situaitons. Get it from http://huchra.bufferbloat.net/~cero1/cerowrt-wndr3700-1.0rc6/ Use the openwrt-ar71xx-generic-wndr3700v2-squashfs-factory.img version.

The Cerowrt Installation Guide gives good information about installing and configuring these builds. 

----- That's it! -----

Best regards from cloudy and chilly New Hampshire.

Rich Brown