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
