Date: Wed, 12 Sep 2012 10:43:50 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: [CFT] ath_rate_sample fixes for 11n Message-ID: <CAJ-VmokCNZcFvbL4KkWsn8YZr4TEFpzop1zpaPrCcoyTt6p5vA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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
slow.
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
environment;
* 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.
Thanks,
Adrian
[-- Attachment #2 --]
Index: dev/ath/ath_rate/sample/sample.c
===================================================================
--- dev/ath/ath_rate/sample/sample.c (revision 240333)
+++ dev/ath/ath_rate/sample/sample.c (working copy)
@@ -293,27 +293,17 @@
}
/*
- * When doing aggregation, successive failures don't happen
- * as often, as sometimes some of the sub-frames get through.
- *
- * If the sample rix average tx time is greater than the
- * average tx time of the current rix, don't immediately use
- * the rate for sampling.
+ * For HT, only sample a few rates on either side of the
+ * current rix; there's quite likely a lot of them.
*/
if (an->an_node.ni_flags & IEEE80211_NODE_HT) {
- if ((sn->stats[size_bin][rix].average_tx_time * 10 >
- sn->stats[size_bin][current_rix].average_tx_time * 9) &&
- (ticks - sn->stats[size_bin][rix].last_tx < ssc->stale_failure_timeout)) {
+ if (rix < (current_rix - 3) ||
+ rix > (current_rix + 3)) {
mask &= ~((uint64_t) 1<<rix);
goto nextrate;
}
}
- /*
- * XXX TODO
- * For HT, limit sample somehow?
- */
-
/* Don't sample more than 2 rates higher for rates > 11M for non-HT rates */
if (! (an->an_node.ni_flags & IEEE80211_NODE_HT)) {
if (DOT11RATE(rix) > 2*11 && rix > current_rix + 2) {
@@ -1420,7 +1410,7 @@
if (ssc == NULL)
return NULL;
ssc->arc.arc_space = sizeof(struct sample_node);
- ssc->smoothing_rate = 95; /* ewma percentage ([0..99]) */
+ ssc->smoothing_rate = 75; /* ewma percentage ([0..99]) */
ssc->smoothing_minpackets = 100 / (100 - ssc->smoothing_rate);
ssc->sample_rate = 10; /* %time to try diff tx rates */
ssc->max_successive_failures = 3; /* threshold for rate sampling*/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokCNZcFvbL4KkWsn8YZr4TEFpzop1zpaPrCcoyTt6p5vA>