Gesendet: Freitag, 08. März 2013 um 20:28 Uhr Von: "Marek Lindner" lindner_marek@yahoo.de An: "The list for a Better Approach To Mobile Ad-hoc Networking" b.a.t.m.a.n@lists.open-mesh.org Betreff: Re: [B.A.T.M.A.N.] [PATCH 2/2] batman-adv: make number of broadcasts configurable per hardif
On Saturday, March 09, 2013 01:38:56 Linus Lüssing wrote:
From: Matthias Schiffer mschiffer@universe-factory.net
In heterogenous networks, setting the number of broadcasts to differing values on different interfaces can be beneficial.
E.g., on wireless interfaces with high packet loss a higher number of broadcasts may be necessary, whereas on low-bandwidth interfaces with relatively high reliablily (such as VPN links over slow internet lines) sending only a single packet makes more sense to preserve bandwidth.
In general, I like the idea but the approach isn't the best. Can't we automate these settings instead of adding hundreds of little knobs nobody will understand ? Why not detecting wifi interfaces as such and configure the broadcast value accordingly ? The same goes for ethernet / vpns ?
I like the idea of automating things, especially if the automated mechanism isn't too complex and therefore I like the idea of Matthias latest patch. And it helps us just as well for our setup.
Nevertheless I'm still wondering, whether a manually configurable number of broadcast might be of general interest, not only for debugging and not only for obscure scenarios.
Two things I could think of: A scenario where people might use a higher multicast rate, where maybe a slightly higher rebroadcast number might become necessary. Or for wifi longshots, which could have a very changing, whether dependant link quality (while generalizing a dynamic number of broadcast isn't that easy, it's very easy to write a script to check the current link-quality (or even the local whether station :) ) towards the target which adjusts the number of rebroadcasts from this upper level.)
What do the others think? Or are such scenarios still too obscure to justify the addition of such a sysctl parameters? Has anyone on this ML maybe had a setup where s/he thought such a sysctl parameter could be useful?
Cheers, Linus
Cheers, Marek