As Axel said, I have performed an independent measurements. <br>You can find a summary here:<br><br><a href="http://dabax.net/wbm/pau/analysis.pdf">http://dabax.net/wbm/pau/analysis.pdf</a><br><br>Also here: <a href="http://dabax.net/wbm/pau">http://dabax.net/wbm/pau</a> you can find all the raw data, and more other graphs.<br>
<br>Please, report any bug :-D<br><br><div class="gmail_quote">2011/3/27 Axel Neumann <span dir="ltr"><<a href="mailto:neumann@cgws.de">neumann@cgws.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Samstag 26 März 2011, Juliusz Chroboczek wrote:<br>
> Interesting. Thanks to all of you for compiling this data.<br>
><br>
> Axel, could we have a histogram of the distribution of protocol packet<br>
> sizes?<br>
<br>
</div>So somebody must generate it ;-)<br>
I would also be interested, But I wont find time for this now.<br>
Find the raw tcpdump logs for each measurement<br>
at: <a href="http://dabax.net/wbm/axel/raw-data/" target="_blank">http://dabax.net/wbm/axel/raw-data/</a> *.rawdump . They are truncated to 80<br>
bytes but should be enought for what you are looking for.<br>
<br>
As far as I know Pau is currently also postprocessing completely independent<br>
measurements. And I we once already discussed to present specific<br>
distributions. But he'll tell you more soon...<br>
<div class="im"><br>
><br>
> A few comments, after staring at it for just a few minutes:<br>
><br>
> (1) I'm impressed by the good results of BMX6. Axel, is there<br>
> a detailed description of the protocol?<br>
<br>
</div>Yes! some very detailed comments in .c and help files in .h format :-)<br>
<br>
<br>
If you are addressing the metric algorithm I can give some more info:<br>
<br>
I implemented and tested variations of TQ, ETX, ETT (ETT only estimating link<br>
bandwidth). You can easily lookup the supported algorithms straight in the .c<br>
comments (eg ETX-alike path_metric_ExpectedQuality() function:<br>
<a href="http://doxygen.bmx6.net/bmx6/html/db/d2a/metrics_8c-source.html#l00358" target="_blank">http://doxygen.bmx6.net/bmx6/html/db/d2a/metrics_8c-source.html#l00358</a> )<br>
<br>
The main difference in bmx6 is that a greater metric value represents a better<br>
metric. And some confusion caused by range scaling for better calculation<br>
precision ( [0..1] input range transfomed to [0...UMAX] and back ).<br>
<br>
The bmx6 default metric_algorithm (also used during the battle) is a bit the<br>
result of my experience and feeling.<br>
<br>
If you think of<br>
ETT_next = ETT_incoming_path + ETT_incoming_link where<br>
ETT_incoming_path represents the expected transmit time over the so-far-<br>
traversed path (without the last hop) and<br>
ETT_incoming_link represents the assumed ETT via just the last hop.<br>
<br>
then<br>
the bmx6 default path_metricalgo_VectorBandwidth() would do something like:<br>
ETT_bmx6 = sqrt( ETT_incoming_path^2 + ETT_incoming_link^2)<br>
The idea is to apply less penalty for additional hops that original ETT would.<br>
<br>
To better reflect asymmetric links also ETT_incoming_link is a bit tuned:<br>
ETT_incoming_link is calculated from the detected link-packet loss and an<br>
assumed ETT_LINK_MIN (1/1Gbps for wired and 1/56Mbps for wireless links) as:<br>
ETT_incoming_link = ETT_LINK_MIN / ( TQ * sqrt(RQ) )<br>
<br>
Might not be the RFC you were looking for but this is all I can offer right<br>
now.<br>
<font color="#888888"><br>
/axel<br>
</font><div><div></div><div class="h5"><br>
><br>
> (2) No loops in Babel and BMX6, as expected. Some loops in BATMAN,<br>
> which I don't understand. Moderate number of loops in OLSR, as<br>
> expected. No data for BATMAN-adv.<br>
><br>
> (3) The issue with Babel having high protocol overhead in marginal<br>
> networks is still present, as expected. This is due to Babel sending<br>
> a bunch of explicit requests whenever it loses a route (Section 3.8.2.1<br>
> of RFC 6126); I'm considering a fix that would consist in rate-limiting<br>
> the requests, but I need to get the details right.<br>
><br>
> (4) Surprisingly low protocol overhead for OLSR. Counter-intuitively<br>
> enough, OLSR's strategy which consist in having no adaptative intervals<br>
> at all appears to pay off in this particular case.<br>
><br>
> (5) Although Babel was being run with a higher hello interval, its<br>
> performance in the mobility scenarios was as good or better than that of<br>
> the other protocols.<br>
><br>
> --Juliusz<br>
> _______________________________________________<br>
> Battlemesh mailing list<br>
> <a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
> <a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
<br>
_______________________________________________<br>
Battlemesh mailing list<br>
<a href="mailto:Battlemesh@ml.ninux.org">Battlemesh@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/battlemesh" target="_blank">http://ml.ninux.org/mailman/listinfo/battlemesh</a><br>
</div></div></blockquote></div><br>