<font face="arial" size="2"><p style="margin:0;padding:0;">A small suggestion.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Create a regression test suite, and require contributors to *pass* the test with each submitted patch set.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Be a damned Nazi about checkins that don't meet this criterion - eliminate the right to check in code for anyone who contributes something that breaks functionality.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Every project leader discovers this. Programmers are *lazy* and refuse to check their inputs unless you shame them into compliance.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Thursday, April 5, 2012 10:27pm<br />To: cerowrt-devel@lists.bufferbloat.net<br />Subject: [Cerowrt-devel] Cero-state this week and last<br /><br /></p>
<div id="SafeStyles1333679396">
<p style="margin:0;padding:0;">I attended the ietf conference in Paris (virtually), particularly ccrg<br />and homenet.<br /><br />I do encourage folk to pay attention to homenet if possible, as laying<br />out what home networks will look like in the next 10 years is proving<br />to be a hairball.<br />ccrg was productive.<br /><br />Some news:<br /><br />I have been spending time fixing some infrastructural problems.<br /><br />1) After be-ing blindsided by more continuous integration problems in<br />the last month than in the last 5, I found out that one of the root<br />causes was that the openwrt build cluster had declined in size from 8<br />boxes to 1(!!), and time between successful automated builds was in<br />some cases over a month.<br /><br />The risk of going 1 to 0 build slaves seemed untenable. So I sprang<br />into action, scammed two boxes and travis has tossed them into the<br />cluster. Someone else volunteered a box.<br /><br />I am a huge proponent of continuous integration on complex projects.<br />http://en.wikipedia.org/wiki/Continuous_integration<br /><br />Building all the components of an OS like openwrt correctly, all the<br />time, with the dozens of developers involved, with a minimum delta<br />between commit, breakage, and fix, is really key to simplifying the<br />relatively simple task we face in bufferbloat.net of merely layering<br />on components and fixes improving the state of the art in networking.<br /><br />The tgrid is still looking quite bad at the moment.<br /><br />http://buildbot.openwrt.org:8010/tgrid<br /><br />There's still a huge backlog of breakage.<br /><br />But I hope it gets better. Certainly building a full cluster of build<br />boxes or vms (openwrt@HOME!!) would help a lot more.<br /><br />If anyone would like to help hardware wise, or learn more about how to<br />manage a build cluster using buildbot, please contact travis<br /><thepeople AT openwrt.org><br /><br />2) Bloatlab #1 has been completely rewired and rebuilt and most of<br />the routers in there reflashed to Cerowrt-3.3.1-2 or later. They<br />survived some serious network abuse over the last couple days<br />(ironically the only router that crashed was the last rc6 box I had in<br />the mix - and not due to a network fault! I ran it out of flash with a<br />logging tool).<br /><br />To deal with the complexity in there (there's also a sub-lab for some<br />sdnat and PCP testing), I ended up with a new ipv6 /48 and some better<br />ways to route that I'll write up soon.<br /><br />3) I did finally got back to fully working builds for the ar71xx<br />(cerowrt) architecture a few days ago. I also have a working 3.3.1<br />kernel for the x86_64 build I use to test the server side.<br />(bufferbloat is NOT just a router problem. Fixing all sides of a<br />connection helps a lot). That + a new iproute2 + the debloat script<br />and YOU TOO can experience orders of magnitude less latency....<br /><br />http://europa.lab.bufferbloat.net/debloat/ has that 3.3.1 kernel for x86_64<br /><br />Most of the past week has been backwards rather than forwards, but it<br />was negative in a good way, mostly.<br /><br />I'm sorry it's been three weeks without a viable build for others to test.<br /><br />4) today's build: http://huchra.bufferbloat.net/~cero1/3.3/3.3.1-4/<br /><br />+ Linux 3.3.1 (this is missing the sfq patch I liked, but it's good enough)<br />+ Working wifi is back<br />+ No more fiddling with ethtool tx rings (up to 64 from 2. BQL does<br />this job better)<br />+ TCP CUBIC is now the default (no longer westwood)<br />after 15+ years of misplaced faith in delay based tcp for wireless,<br />I've collected enough data to convince me the cubic wins. all the<br />time.<br />+ alttcp enabled (making it easy to switch)<br />+ latest netperf from svn (yea! remotely changable diffserv settings<br />for a test tool!)<br /><br />- still horrible dependencies on time. You pretty much have to get on<br />it and do a rndc validation disable multiple times, restart ntp<br />multiple times, killall named multiple times to get anywhere if you<br />want to get dns inside of 10 minutes.<br /><br />At this point sometimes I just turn off named in /etc/xinetd.d/named<br />and turn on port 53 for dnsmasq... but<br />usually after flashing it the first time, wait 10 minutes (let it<br />clean flash), reboot, wait another 10, then it works. Drives me<br />crazy... Once it's up and has valid time and is working, dnssec works<br />great but....<br /><br />+ way cool new stuff in dnsmasq for ra and AAAA records<br />- huge dependency on keeping bind in there<br />- aqm-scripts. I have not succeed in making hfsc work right. Period.<br />+ HTB (vs hfsc) is proving far more tractable. SFQRED is scaling<br />better than I'd dreamed. Maybe eric dreamed this big, I didn't.<br />- http://www.bufferbloat.net/issues/352<br />+ Added some essential randomness back into the entropy pool<br />- hostapd really acts up at high rates with the hack in there for more<br />entroy (From the openwrt mainline)<br />+ named caching the roots idea discarded in favor of classic '.'<br /><br /><br />-- <br />Dave Täht<br />SKYPE: davetaht<br />US Tel: 1-239-829-5608<br />http://www.bufferbloat.net<br />_______________________________________________<br />Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/cerowrt-devel</p>
</div></font>