On Sun, Apr 5, 2015 at 5:43 AM, Juliusz Chroboczek <[email protected]> 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 _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
