[Battlemesh] Open Tasks - once again / And some questions

Wed Apr 8 19:30:09 UTC 2015

On Sat, Apr 4, 2015 at 5:16 PM, Bernd Naumann <bernd at kr217.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Simon,
> Hi at all,
>
> On 04/01/2015 07:06 PM, Simon Wunderlich wrote:
>> * Test preparation/management - create test scenarios or adopt from
>> last year, prepare and discuss them with teams, organize
>> evaluation. As you may know, this is a challenging, but very
>> interesting task :)
>
> are there any written notes or code examples on configuration,
> measuring and plotting results?
>
> * http://battlemesh.org/NetworkConfiguration ?

My dream was to try to get you all to adopt netperf-wrapper.

30+ interesting tests, universal plotting format, scriptability, great
gui for making
many, many different comparison plots, etc. It uses far more than netperf
now, including voip testing tools in particular, so it is increasingly misnamed.

I am willing to work on defining scriptable tests - in that - in
addition to what we have already.

I have been busy with other projects of late (notably make-wifi-fast,
but also the
design of a fq_codel replacement) but can start to clear some time next month.

In the meantime, please give netperf-wrapper a shot. In particular the rtt-fair
tests are VERY appropo for wifi tests, and the rrul test explicitly
abuses 802.11e.

https://github.com/tohojo/netperf-wrapper

It is written in python and easy to extend.

I realize that we also want to compare the actual performance of the routing
protocols and their message traffic, and inject mobility and loss
events, and so on, netperf-wrapper might (or might not)
be a decent substrate.

As some examples of plots and data that might be of use at battlemesh:

a)  recently candelatech did a whole series of multistation rtt_fair
tests against the most common new 802.11ac routers out there.

netgear3700v2 - 1.0.0.12
netgear6300 - v1.0.2.70_1.0.50
netgear7000 - dd-wrt-23884M
dlink-dgl5500 - 1.11b03
linksys1900ac - 1.1.7.160582
asus-rt-ac66r - 3.0.0.4.374_5517

Here's a comparison plot of box totals:
http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png

Here's a tarball of all the test results for browsing in netperf-wrapper:

http://candelatech.com/downloads/rtt_fair4be-ap-tests.tgz

b) my own work is presently most focused on better queue management
along the edge of the cable network. These are plots of behavior of
all the new ones on the table (fq_codel, cake, fq_pie, ns4_codel, pie)
at comcast´s 115/12Mbit rates, including the "standard" pfifo_fast
qdisc:

http://snapon.lab.bufferbloat.net/~d/cake3-fixed/baseline.png #
comparison of qdiscs vs pfifo_fast - note the extra bandwidth on the
download for pfifo_fast is not as real as it might look - it is the
native rate - vs the shaped to a safe value rate.

tarball dataset: http://snapon.lab.bufferbloat.net/~d/cake3-fixed-tests.tgz

c) various other examples of cool graphs

http://snapon.lab.bufferbloat.net/~d/sqm_cake3_archer.png # tcp up/down/ping
http://snapon.lab.bufferbloat.net/~d/cake3-fixed/ellipsis.svg #
comparison of bandwidth and latency variance

>
> # Deploying nodes in the area
>
> I have an other question in more general: if I remember correctly,
> last year many tests happened with nodes really close to each other
> (all on one table).
>   Is there any reason in this, besides - it was more difficult to
> scatter the nodes over the area like in copenhagen it was (I saw the
> walkaround video clip, which was quiet cool to show around, to
> illustrate the battlemesh-sphere ;-)?

I would like to see both dense and distant mesh stuff tested.

>   How will be the situation at the spot this year? I saw that it might
> be possible to do long-shots, too. Do we have access to the area? Do
> we can build a real world scenario?
>
>
> # Simulate disruption
>
> An other thing: What could I do if I do not have access to a large
> area and want to simulate disruption in a mesh network virtually? Like
> changing legacy or available bandwith with linux kernel features, or
> is there even a way to simulate bad ETX-values on the mesh layer via
> the kernel?
>
>
> # Testbeds at the battlemesh
>
> And as I am writing right now, a third and hopefully last thing:
> Last year I didn't understood the topology of the network, so is there
> a separated /stable/ network for accessing the internet (?), but how
> are test-networks organised? Are there several networks from different
> groups, and when and how someone can participate, learn and maybe help
> with something while building and testing?
>
>
> # Bonus: `owrtconfig`-fork
>
> As someone might have seen at the freifunk-list, I found an old
> battlemesh-script and edited it: `owrtconfig` .
>   I added the feature to flash many devices for the first time
> (`owrtflash.sh`) with help from `curl` and the arp-foo already in
> `owrtconfig.sh`. Someone will may find it useful or give feedback/add
> some stuff.
> You can find my modification at
> https://github.com/ptrhere/owrtconfig/compare/master...L337hium:master
>
> Pull-requests with curl-scripts to support more devices are very
> appreciated because I only have limited access to different devices.
> But you can also test the tp-link scripts on other firmware versions
> and/or similar models, maybe the scripts could be executed with minor
> modifications. (hint/srly: firefox developer tools ftw!)
>
> Thank you and many greetings from Weimar,
> Bernd
>
> - --
> Bernd Naumann <bernd at kr217.de>
>
> PGP:   0xA150A04F via pool.sks-keyservers.net
> XMPP:  bn at weimarnetz.de
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iQIcBAEBAgAGBQJVIH7kAAoJEEYW3OihUKBPuvIP/1GtEeToEmbKjTKG/HthBPqO
> FqDGCbENHAMlDGoMfpQK7khXIEBCj5E4+jDgzbyEMMQ4ZqNApQ/h5bLnJ9gQzpLN
> cEwTZFIBhd+qS+liOHMFMKwbOncLv/gsmPMsmktRe5ZQSua2wyGKEAJpv4txAkUQ
> JHQIjoZjGH4nEOM1szW+kg/KjBz1Hh5cQNPoukCu1yaiVvUD/yhJknX4tTJDPiGD
> DembW/XpVi7EQK+Q1lCMxgO+R3eHCfSZ3F6WlV9xk3x4cfvjI4esUnQj0G3TqdWn
> xQbzidLKJh1I/ZJw9HX3/rS03h4ei3DnTvhSz0FnAFhjb8hrYu7rv/GpgrdnBNnD
> jyoWEF4lECzTrtHTwbZF39X0DYsmckyEk875lWrCnvlwGkuwZK+1dv6B2khOsZ28
> AiSBy6EljM7WaaX33okKHDpnYJZ3LTbsqVTik2aV6fb9o9MIhOTrUpti1YkMBMYI
> 8k41wfpjfZgqGS6WwmMrQ5DCIZJBr2zqOIysw7xvTlT7ohIJxtEcBdW392elTUug
> aA/f2kk+Ylh78ntIB/N9nljlsBQ+92aa7FMK51JjLr2WRJbsTLgdhChoZS1TNCXB
> JhnLtuPxTALcSYl0k6/Xx0/OsNkCjBy/jcgSS49PxVymfN4iO1mZmqBdWX+08DxA
> QnQaNVmVi40z9aVx6lUu
> =ET9F
> -----END PGP SIGNATURE-----
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh

-- 
Dave Täht
We CAN make better hardware, ourselves, beat bufferbloat, and take
back control of the edge of the internet! If we work together, on
making it:

https://www.kickstarter.com/projects/onetswitch/onetswitch-open-source-hardware-for-networking