Hello, 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? Thanks Keep smiling yanosz
