Re: [B.A.T.M.A.N.] [PATCH] batman-adv: increase default hop penalty

["Jay Brussels" <jay@dslx.net>]

I will be setting up a test network with 20-25 radio's before our big
roll-out.  I can make the network available for testing if that would help
at all.

-----Original Message-----
From: B.A.T.M.A.N [mailto:b.a.t.m.a.n-bounces@lists.open-mesh.org] On Behalf
Of Simon Wunderlich
Sent: Thursday, June 19, 2014 12:18 PM
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: increase default hop penalty


> On Wed, Jun 18, 2014 at 11:21:14AM +0200, Simon Wunderlich wrote:
> > > Any data for others to check?
> > 
> > Nope, unfortunately these are customer networks, and I can't reveal 
> > data from that in public.
> 
> That's very, very unfortunate... and made my hair stand on end. It 
> clashes/undermines a little with a point I love a lot about free 
> software... Anyways, maybe that's not something to discuss on a 
> mailing list.

I don't quite get why you are so emotional about that. There are tons of
other default settings and "heuristic" values which we determined with much
less "scientific" effort - e.g. the wifi penalty, local window size, request
timeout, tq global window size, broadcast number ... and nobody cried about
setting these values or changing them.

I understand that it would be nicer to get all data in public, but open
software is used in private and/or commercial environments as well and we
should respect that these people don't want their network topology revealed.

These networks are not public playground. Of course, if you want you can
repeat these kind of experiments in your community or test mesh networks
(weren't there some EU projects who offered that kind of stuff? :] )

> 
> Damn it, why don't we have the stupid hop count in the measurements 
> from the last WBM? Would have been very easy to verify with that.

Very easy ...? Well, if you think so, please propose/perform/evaluate these
tests in the next battlemesh. :)

> 
> Maybe we could try using the WBM to transparently find better default 
> values in the future (again; I remember that you had made nice graphs 
> for the decision of having interface-alternating or interface-bonding 
> as the default back then at WBMv3 in Italy - that was awesome!)?

Yeah, that wasn't so bad, but the tests were not very extensive too - 3
devices with special hardware and setup. We could show the gains of
alternating/bonding after all ... ;)

In any case, feel free to propose these kind of tests for next WBM.

> 
> > But I can certainly explain how I tested: We were running Antonios 
> > throughput meter on these devices and saw some unusual slow 
> > throughput and too long paths (4 hops were 2 were possible). We then 
> > increase the hop penalty to the suggested value, and both the 
> > hopcount decreased and the throughput increase. We repeated that 
> > with other 6 networks and had either similar improvement or no 
> > change at all (since all hopcounts were already one).
> 
> What mcast-rate were you using? Will this make things worse for setups 
> with a different mcast-rate?

The mcast rate was 18M. I don't know if it gets "worse" for different MCS
rates, and it depends what we think is "worse". In general, I'd expect that
the protocol chooses longer links /shorter paths, for all mcast rates.

Cheers,
    Simon