Hello, Am 05.01.2013 um 10:47 schrieb Jan Lühr:
> Am 05.01.2013 um 00:28 schrieb NicoEchániz: >> On 01/04/2013 02:41 PM, Marek Lindner wrote: >>> On Friday, January 04, 2013 23:12:59 NicoEchániz wrote: >>>>> Selection class 3 and beyond do change the gateway when a better one >>>>> becomes available. But as you correctly pointed out these selection >>>>> classes don't consider the announced bandwidth for the simple reason >>>>> that nobody cared. In most wireless scenarios (the main playground for >>>>> batman-adv) the path towards the gateway turned out to be more critical >>>>> than the gateway's pipe to the internet. >>>>> >>>>> Feel free to propose something if you care about having this option. The >>>>> necessary code shouldn't be too hard to add. Backward compatibility will >>>>> be more difficult to achieve. >>>> >>>> I believe that those of us who chose to use selection class 1 would >>>> prefer if it were "dynamic". So if a new gateway appears, then the >>>> client would evaluate with the same previous criteria if it is better or >>>> not (considering "the gateway's advertised throughput as well as the >>>> link quality") and switch accordingly. I see no reason why when someone >>>> chooses selection class 1 she would be expecting to choose the best >>>> available gw once and not ever check again. >>>> >>>> If a network is stable, when a new better gw appears in some area it >>>> won't be selected until nodes are restarted, and that might be a long time. >>> >>> You misread my statement. Nobody needs to be convinced of the usefulness of >>> such a feature (at least for what concerns myself). Somebody needs to come >>> up >>> with a solid proposal which then needs to be implemented. That is what I >>> meant >>> by saying "Feel free to propose something [..]". >> >>>> One other change that might be interesting would be the addition of a >>>> setting for how much the advertised throughput affects gw selection. >>>> I've seen Jan uses 96/96Mbit as advertised throughput on one router; I >>>> do the same on our "main gateway", but maybe it would be better if we >>>> could actually advertise the real throughput and have a setting to >>>> control how much the bandwidth difference affects the selection. >>> >>> Again, feel free to propose something which can be discussed. >> >> It could just be implemented as a new setting like: gw_bw_weight >> >> which would regulate how much gw bandwidth/throughput affects best gw >> calculation. >> >> I don't know what's the current algorithm but I guess there would be no >> problem with backwards compatibility here; if the value is not set, the >> default should produce the same result we get now. >> >> >> So to make the proposal clear: >> >> I'd change options for gw_mode client to something like this: >> >> gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ) >> >> gw_tq_threshold [3...256] >> the minimum TQ delta to switch to a better gw, defaults to 20. >> >> gw_bw_weight [value from 0 to 1] >> how much does advertised gw bandwidth affect the selection. 0 does not >> affect selection, 1 has most effect. Defaults to 1 but has no effect if >> gw_sel_class is 2. >> >> For backwards compatibility, if gw_sel_class > 2, it should behave as >> the proposed option 2 with gw_tq_threshold set to the actual value. So, >> for example gw_sel_class 20 would be "translated" to: gw_sel_class 2, >> gw_tq_threshold 20, al least until it's deprecated. > > > I guess, we'll be fine with this. However, it's not clear to me, in what way > (formula) gw_bw_weight will actually influence the selection process. > Do you have any proposals? Ok, I make one - for Link-Usability (or attractiveness, or whatever you like) LU, Gateway-Class GC and TQ: LU = (1 - gw_bw_weight) * TQ + gw_bw_weight * GC gw_tq_threshold should then be renamed to gw_lu_threshold. However, that implies, that TQ and GC should are linear in LU and that min( TQ ) = min ( GC ) as well as max ( TQ ) = max( GC ). I'll be fine with the assuming that TQ and GC should be linear in LU - GC can be scaled such that the min / max condition holds LU = (1 - gw_bw_weight) * TQ + gw_bw_weight * ( c1 * GC + c2) (for contants c1, c2) @Marek, Nico : What Do you think? Keep smiling yanosz
