On Fri, Sep 7, 2012 at 4:54 AM, Andy S <[email protected]> wrote: > > On 6 September 2012 17:20, Dave Taht <[email protected]> wrote: >> >> The ubnt builds are a bit out of date (part of my test deployment of >> fq_codel at a campground here - the yurtlab! >> http://snapon.lab.bufferbloat.net/~d/lupin/yurtlab.jpg which is >> blessedly free >> of competing wifi signals) >> >> They are also a little specialized. Among other things, they have my >> ssh public key in them, >> and are keyed to local dns, they rely on the babel protocol to route >> and mesh together, although they do come up presently on a fixed ip >> address that needs to be changed, instead of relying on AHCP for their >> IPs and dns. >> >> All of quagga (including OSPF) IS built, it's just that babel is the >> default. >> >> In working with this build and test deployment I exposed some problems >> with memory usage in codel and the ath9k driver. Quagga will get >> OOM-killed under heavy loads, such as RTP and UDP flooding across >> multiple diffserv values, on the 2HP boxes in AP mode. The p2p >> backbone (nanostation M5s) has never crashed on me. >> >> This points long term towards developing a "mfq_codel", which would >> have one qdisc and *one* set of buffers that controls all four >> hardware queues. However, try as I might, I haven't wrapped my head >> around how to merge the code for sch_mq and sch_fq_codel, in a way >> that would work. (?) >> >> Aside from that it's working rather well, and the hacks I have in >> place now to reduce skb size seem to help a lot. >> >> Now that the memory problems are mostly beaten I will be doing a >> respin and re-deployment towards the end of the month. If I can build >> something a little more generic and easy to deploy on ubnt for others, >> I will do so, getting to where all this code runs well in 32MB is >> rather important to me. >> >> Let me know. >> >> On Thu, Sep 6, 2012 at 4:17 AM, Andy S <[email protected]> wrote: >> > I see that there are UBNT builds available for specific deployment >> > scenarios; we use Ubiquiti Bullet M5's on some parts of our (city-wide) >> > 5.8Ghz wireless network, but they don't support OSPF, so if any of the >> > builds of Cerowrt support Bullet M5 and OSPF (I see the Quagga-ospf >> > modules >> > available in the main devel builds) - we would be interested to >> > hear/test! >> > >> > Cheers, >> > >> > A >> > -- >> > http://www.bristolwireless.net/ | 0117 325 0067 | >> > sip:[email protected] >> > Bristol Wireless >> > Windmill Hill City Farm >> > Philip Street >> > Bedminster >> > Bristol BS3 4EA >> > >> > >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > [email protected] >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > >> >> >> >> -- >> Dave Täht >> http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out >> with fq_codel!" > > > Sounds great, still none the wiser as to whether your builds will work on > the Bullet or not, as the Bullet and NanoStation run different software by > default. > > Most of what you guys do is waaay over my head, but I'm keen to try stuff > out, although this may necessitate a sacrificial Bullet!
Once a UBNT devices image is built itll run for the most part, guess i could spend some time today pitching in and see if one can be created though size might become an issue. Ill run a build and see what happens, Ive got some Picos here i can flash > > Keep us posted! > > A > > > -- > http://www.bristolwireless.net/ | 0117 325 0067 | > sip:[email protected] > Bristol Wireless > Windmill Hill City Farm > Philip Street > Bedminster > Bristol BS3 4EA > > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
