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