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

Thu Apr 9 19:33:18 UTC 2015

Please disregard as unnecessary :-)

But I (resistantly) think he has a point somewhere...

Dave Taht skrev den 2015-04-08 21:30:
> On Sat, Apr 4, 2015 at 5:16 PM, Bernd Naumann <bernd at kr217.de> wrote:
> 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.
> 

gui? Caveman style point and barf?

>> 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'm sorry, I'm just to old for languages that does not adopt to human
behavior (Yes, perl!)
> 
>> 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
> 
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
> 
> 
> 

-- 
Christian Huldt
+46704612207

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20150409/c052596f/attachment.pgp>