[mesh-dev] Hacknight progress

[Dave Taht]

If y'all ever get out of SF, it is burner weekend at my site in los gatos... :)

I will be leaving for europe in mid-july, but have an established mesh here you
might want to look over, if you want.

On Fri, Jun 26, 2015 at 8:28 AM, Marc Juul <juul at labitat.dk> wrote:
> Here's what went down.
>
> # Added functionality to our babeld fork
>
> -x for dynamically removing interfaces (we only had -a to add them)
> -F to enable the dynamic functionality (fungible mode)
> -i to print the "kill -USR1" information for the running babeld

> babeld no longer requires any interfaces to be specified when initially
> started if fungible mode is enabled
>
> # Switched our firmwares to using our babeld fork
>
> Here it is:
> https://github.com/sudomesh/sudowrt-packages/tree/master/net/babeld-sudowrt

1.6.0 added ipv6 source specific routing. 1.6.1 was a bug fix.

I believe in all cases, that
channel diversity is still broken in AP mode (the world moved to
nl80211), but might
still be correct for adhoc.

havent had the energy to copy/paste from the iw code over to babel.

>
> We were only using them on the VPuN (exit) server before.

I am curious if you have also implemented the sqm-scripts there?
(measure your latency
with tools like flent)


> I haven't tried to recompile the firmware with this package added. Maybe
> someone else can test that this compiles correctly?
>
> max: be aware that VPuN servers will now have to start new versions with -F
> to get the dynamic functionality
>
> # Completed extender-node functionality
>
> Everything now works as expected with babeld running on the extender nodes.
> The extender nodes come up automatically and both the open and adhoc
> networks work.

I note that you do have to set BSSID consistently throughout the mesh.

My own mild fork of babel was adding ecn support recently (as all my
nodes run fq_codel or cake with ecn enabled). This showed that a large
percentage of the routing issues I was having were actually congestive
in nature.

Of course, not having enough packet loss is also a problem. Setting
mcast_rate to something high helps on a variety of fronts. On the
picos I have gone as high as mcast_rate 9000, and might go higher,
given how promisquiously they connect.

It is also generally a good idea to turn off wmm.

>
> Due to feedback by Dave Taht I abandoned adding avahi-daemon as a reflector
> on the extender nodes and pushed forwarding of mDNS traffic to the milestone
> for a future release.
>
> The one thing left to do for the extender nodes is to re-compile both
> firmwares from scratch, flash two nodes and test that it all comes up as
> expected. I've tried hard to bring the repositories in line with the working
> configuration on my two test nodes, but I may have missed something.

I have been testing successfully the new minstrel-blues (coupled power
and rate control) stuff along with andrew mcgregor's minimum variance
patches. Have not pushed them to openwrt, but they are part of my
default build.

The minimum variance stuff is neat - instead of choosing the best
average rate (which may vary wildly), minstrel now chooses the most
consistent rate, which makes tcps happier and makes for more
consistent results on other protocols, like voip. Patches have been
appying to chaos calmer and trunk for 4+ months now...

http://snapon.lab.bufferbloat.net/~cero3/minstrel_variance.tgz

> # Added milestones and issues on github
>
> Milestones:
>
> https://github.com/sudomesh/sudowrt-firmware/milestones
>
> Issues for upcoming version 0.2:
>
> https://github.com/sudomesh/sudowrt-firmware/milestones/0.2%20-%20initial%20developer%20release
>
> Please add any issues I may have missed. Also, please change things if you
> disagree :) I just did what I thought made sense but I'm not married to
> anything.

I am always also looking for more testers of "cake", which is in the
ceropackages-3.14 repo (along with tc-adv).

I started applying it to wifi recently (killing off mq entirely) with
a bandwidth limit. This cut memory use under congestive load by a lot
and seems to work well. Cake is not, however, anywhere near as baked
as minstrel-blues nor is it actually targetted at wifi. (that's
make-wifi-fast)

http://www.bufferbloat.net/projects/codel/wiki/Cake




> Yay progress!
>
> --
> marc/juul
>
>
> _______________________________________________
> mesh-dev mailing list
> mesh-dev at lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/mesh-dev
>



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast