Search Linux Wireless

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014-03-29 18:23 GMT+04:00 Antonio Quartulli <antonio@xxxxxxxxxxxxxx>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux