Hi all,

Now that I have a live, convenient way of visualising the rate control
data, I decided to do a bit of digging into why HT rate recovery is so

Here's what I've found:

* the default EWMA smoothing rate (95) is resistant to change - both
temporary hiccups in the environment AND sudden improvements in the
* the sampling was occuring across the whole set of MCS rates - and
there's potentially a LOT of them!;
* i was avoiding sampling rates that were failing (but not enough to
fail the WHOLE aggregate frame) - which unfortunately meant that it
would take up to 10 seconds to start considering sampling those rates
and I'd only ever sample them once every 10 seconds.

The last one is the kicker. I inserted some logic to delay sampling HT
rates whose average TX time were 10% higher than the current best HT
rate. Unfortunately this meant I only sampled it once every 10 seconds
and would do that until the average TX time dropped to with 10% of the
best rate. This could take a looong time.

So, with this patch, HT rate control seems to behave slightly more
usefully in changing environments. It may not "stay" on a high rate in
the face of temporary interference but it's likely "good enough" for
most situations. It definitely fixes the HT rate _recovery_ issues
that I see.

Now if you really _DO_ want the rate control code to stick with a
higher rate in the face of some errors and get that little bit more
TCP/UDP throughput, please help me test this and then I'll give you
some little tasks to research and code up.

Barring any real significant performance drops in my testing over the
next couple days or any weird reports from you users, I plan on
committing this rate control change by the weekend.



Attachment: 20120912-sample-ht-fixes.diff
Description: Binary data

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to