[Babel-users] [PATCH] babel: Basic support for a version string

[Dave Taht]

On Sun, Apr 5, 2015 at 5:43 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
>> 1) It is not clear to me how to generate a release tarball with the
>> VERSION file, instead of git.
>
>> I bummed the tiny script from the dnsmasq tree to parse the release
>> tags and supply the git commit it was based on.
>
> I'll have a look at your patch.

Better patch coming, fully implementing VERSION also for git archive.
Ignore this one.

>> 2) I thought about adding the version to the info supplied to
>> babelweb, but did not poke there
>
> Noted.
>
>> 3) It is not clear from reading the man page if diversity routing and
>> rtt based stuff can be enabled at the same time.
>
> Yes, they can.  Babel doesn't care.
>
>> If both are set, who wins?
>
> They act at different levels, RTT is at the cost level, diversity is at
> the metric level.  Picture:

In my case I would like to turn on timestamping universally, as a means
to eventually infer how to do it more right on short RTTs, gathering
data from the production network.

>
>
>   A -----> B -----> C
>     Cost1    Cost2
>        \     /
>         \   /
>           ⊗
>           |
>           V
>        Metric(A,C)
>
> Ordinary Babel on wireless links:
>
>   Cost = ETX
>   Metric = Cost1 + Cost2
>
> RTT-based Babel on wireless links:
>
>   Cost = ETX + F(RTT)
>   Metric = Cost1 + Cost2
>
> where F is the map defined in Fig. 7 of http://arxiv.org/pdf/1403.3488.pdf .
>
> Babel-Z:
>
>   Cost = ETX
>   Metric = α·Cost1 + Cost2
>
> where α depends on whether A-B and B-C interfere or not.
>
> RTT-based Babel-Z:
>
>   Cost = ETX + F(RTT)
>   Metric = α·Cost1 + Cost2
>
> So everything should work fine, although I'd expect the behaviour to be
> interesting to analyse.

Here I go on the testbed...

>> 4) Also, diversity routing is the default for me, and I would suspect
>> the default for others, so I would suggest flipping the default to
>> true in 1.6.
>
> Not in 1.6.0.  There's a huge change in 1.6.0, and if we run into
> problems, I need to know why.  So the default configuration is not
> changing.

Fine by me. Production is currently -z3 with the occasional bump
in rxcost for very distant nodes that can still "hear" each other
but are bad choices for anything but fallback routing.

I know, I know, I should have bumped the metric instead, and
done it long ago.

>
> I also haven't formally evaluated Babel-Z yet (yeah, I know, it's been two
> years), so I'm still a little nervous about it.
>
>> Should I use github pull requests instead?
>
> If you do, please mail, I don't log into Github usually.

Got it.

>
> — Juliusz



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb