[Babel-users] [Battlemesh] tests for downloads ? and tests follow-ups

[Pau]

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 <neumann at cgws.de>

> 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
> > Battlemesh at ml.ninux.org
> > http://ml.ninux.org/mailman/listinfo/battlemesh
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20110327/0139d550/attachment.htm>