[Battlemesh] Battlemesh v6 conclusions

Dave Taht dave.taht at gmail.com
Tue Jul 30 17:04:17 CEST 2013


I realize here you are trying to measure routing efficiency. My thesis
has long been that bufferbloat and latency under load dramatically
alter routing efficiency in the general case....

Toke and I did some 2-4 hop multi-radio throughput tests on the
cerowrt+babel build that week, (which so far I haven't found) Didn't
manage to  do a comparison between routing technologies. On our stuff
(which uses reduced buffering and fq_codel throughout) we did pretty
well on throughput vs latency...

ufo later setup netperf-wrapper servers for me on a portion of the
battlemesh/freifunk network where I ran a string of of latency vs
throughput tests (tcp bidirectional and rrul) over batman on the
hardware there.

This is a classic lightly bufferbloated trace to a nearby box from 10.61.254.11

http://snapon.lab.bufferbloat.net/~d/battlemesh/rrul/20sec_10.61.254.4_rrul.svg

Note the spike in latency almost exactly matches the drop in throughput.

Throughput and latency to a distant node was even worse:

http://snapon.lab.bufferbloat.net/~d/battlemesh/rrul/20sec_10.61.254.18_rrul.svg

There are a bunch of other tests and raw data here:

http://snapon.lab.bufferbloat.net/~d/battlemesh/

It was unclear to me how to transit the battlemesh net during last
weeks' babel testing with the same tests, so I didn't do that. It was
my hope that fq_codel even without the same ath9k mods (to be_qlen,
etc) would do well underneath all routing protocols.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



More information about the Battlemesh mailing list