On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
> Hi all,
>
> I am currently using 802.11s for a project using openWrt mesh portals.
> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
> "rate"
> which is ultimately computed using sta->last_tx_rate from minstrel.
>
> This last_tx_rate is also updated by minstrel attempts at lower and
> higher speeds. Even if these occasional attempts are outnumbered by
> frames at max_tp_rate[0], they cause unexpected airtime metric
> variations resulting in unneeded mesh path changes.
> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
> not subject to minstrel attempts and directly reflects the speed used
> for the vast majority of the frames.
Interesting -- I tried this exact thing once before, but got mixed results
in my testing.
Can you share your testing strategy?
It's true that last_tx_rate is sub-optimal here, but I feel like using
max_tp_rate directly is a layering violation. Many rate controllers
won't have that concept, and some rate controllers will exist entirely
in firmware. So I think perhaps fixing the concept of "last_tx_rate" or
adding a new "best_tx_rate" field that excludes probes and such might be
the way forward, rather than calling into the rate controllers.
--
Bob Copeland %% http://www.bobcopeland.com
2014-03-29 18:23 GMT+04:00 Antonio Quartulli <[email protected]>:
> Hello,
>
> On 28/03/14 14:22, Bob Copeland wrote:
>> On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
>>> Hi all,
>>>
>>> I am currently using 802.11s for a project using openWrt mesh portals.
>>> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
>>> "rate"
>>> which is ultimately computed using sta->last_tx_rate from minstrel.
>>>
>>> This last_tx_rate is also updated by minstrel attempts at lower and
>>> higher speeds. Even if these occasional attempts are outnumbered by
>>> frames at max_tp_rate[0], they cause unexpected airtime metric
>>> variations resulting in unneeded mesh path changes.
>>> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
>>> not subject to minstrel attempts and directly reflects the speed used
>>> for the vast majority of the frames.
>>
>> Interesting -- I tried this exact thing once before, but got mixed results
>> in my testing.
>>
>> Can you share your testing strategy?
>>
>> It's true that last_tx_rate is sub-optimal here, but I feel like using
>> max_tp_rate directly is a layering violation. Many rate controllers
>> won't have that concept, and some rate controllers will exist entirely
>> in firmware. So I think perhaps fixing the concept of "last_tx_rate" or
>> adding a new "best_tx_rate" field that excludes probes and such might be
>> the way forward, rather than calling into the rate controllers.
>>
>
> Some time ago I raised a similar problem when trying to extract a
> reasonable value from the RC algorithm to be used in a new metric for
> batman-adv.
>
> I wanted something that could represent the "available bandwidth", so
> the first idea was to use "max_tp_rate" and its probability of success.
> Unfortunately these two values are meaningful if we are using minstrel,
> but mostly meaningless for other RC algorithms, therefore nobody (in
> particular Johannes) liked the idea of "exporting" the two separately.
>
> Then we realised that a sort of "estimated throughput/bandwidth" is
> something that any RC algorithm can somewhat provide and that can
> therefore be exported by a generic RC API[1].
>
> The "expected throughput" should be computed by minstrel as the product
> of the max_tp_rate and its probability of success.
>
> I talked a bit about this with Bob on IRC and it seems that this could
> be a viable approach for 11s as well (even if it requires a
> rearrangement of the way ALM is computed).
>
Seems that this could be useful even for end user if we export these
data via NL80211, since last_tx_rate is quite meaningless when using
minstrel rate control.
--
BR,
Sergey
On 29/03/14 19:43, Sergey Ryazanov wrote:
> Seems that this could be useful even for end user if we export these
> data via NL80211, since last_tx_rate is quite meaningless when using
> minstrel rate control.
>
Yeah, this was the second part of the RFC: export the expected
throughput via get_station() and then export get_station() as well so
that also other kernel modules out of mac80211 can use this estimation
(i.e. batman-adv in my case).
Cheers,
--
Antonio Quartulli
Hello,
On 28/03/14 14:22, Bob Copeland wrote:
> On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
>> Hi all,
>>
>> I am currently using 802.11s for a project using openWrt mesh portals.
>> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
>> "rate"
>> which is ultimately computed using sta->last_tx_rate from minstrel.
>>
>> This last_tx_rate is also updated by minstrel attempts at lower and
>> higher speeds. Even if these occasional attempts are outnumbered by
>> frames at max_tp_rate[0], they cause unexpected airtime metric
>> variations resulting in unneeded mesh path changes.
>> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
>> not subject to minstrel attempts and directly reflects the speed used
>> for the vast majority of the frames.
>
> Interesting -- I tried this exact thing once before, but got mixed results
> in my testing.
>
> Can you share your testing strategy?
>
> It's true that last_tx_rate is sub-optimal here, but I feel like using
> max_tp_rate directly is a layering violation. Many rate controllers
> won't have that concept, and some rate controllers will exist entirely
> in firmware. So I think perhaps fixing the concept of "last_tx_rate" or
> adding a new "best_tx_rate" field that excludes probes and such might be
> the way forward, rather than calling into the rate controllers.
>
Some time ago I raised a similar problem when trying to extract a
reasonable value from the RC algorithm to be used in a new metric for
batman-adv.
I wanted something that could represent the "available bandwidth", so
the first idea was to use "max_tp_rate" and its probability of success.
Unfortunately these two values are meaningful if we are using minstrel,
but mostly meaningless for other RC algorithms, therefore nobody (in
particular Johannes) liked the idea of "exporting" the two separately.
Then we realised that a sort of "estimated throughput/bandwidth" is
something that any RC algorithm can somewhat provide and that can
therefore be exported by a generic RC API[1].
The "expected throughput" should be computed by minstrel as the product
of the max_tp_rate and its probability of success.
I talked a bit about this with Bob on IRC and it seems that this could
be a viable approach for 11s as well (even if it requires a
rearrangement of the way ALM is computed).
I also provided an initial RFC[2] that was then rearranged to follow the
"exported throughput" idea but was never re-sent to the ml.
If you think that this is something that could be helpful for you as
well, I could send the new RFC soon so that we can all discuss on it.
Cheers,
[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/118501
[2] http://article.gmane.org/gmane.linux.kernel.wireless.general/118403
--
Antonio Quartulli