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 _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
