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