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

[Bob Copeland <me@bobcopeland.com>]

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 %% www.bobcopeland.com