Skip to contentSkip to conversation

mac80211: Exponential moving average estimate for rc80211_simple

PATCH Superseded Mattias Nissler 1 participant 2 messages Nov 25, 2007 mac80211

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mac80211: Exponential moving average estimate for rc80211_simple

This changes rc80211_simple failed frame percentage estimation to use an exponential moving average method. The old method used the plain tx success/failure counters. This made rate control very unresponsive after a short time of using the interface. Also tune the rc80211_simple parameters a little, so the tx rate is adapted a little more slowly.

---
 net/mac80211/ieee80211_rate.h |    3 -
 net/mac80211/rc80211_simple.c |   87 +++++++++++++++++++++++++++++++---------
 2 files changed, 67 insertions(+), 23 deletions(-)
net/mac80211/ieee80211_rate.h +0 -3
index 2368813..9948d0f 100644
@@ -18,9 +18,6 @@
 #include "ieee80211_i.h"
 #include "sta_info.h"
 
-#define RATE_CONTROL_NUM_DOWN 20
-#define RATE_CONTROL_NUM_UP   15
-
 
 struct rate_control_extra {
 	/* values from rate_control_get_rate() to the caller: */
net/mac80211/rc80211_simple.c +67 -20

157 lines not on this page · raw message

Signature · 1 line
1.5.3.4
#1 lore raw

Hi,

I guess this patch will spawn a discussion, so let me comment a little more.

I have a rt61pci card sitting in the box under my desk. Seems reception isn't really good below my desk :-) With the current rc80211_simple I have the following behaviour: Failed frames accumulate until rc80211_simple decides to lower the rate. Unfortunately, the rate control algorithm is quite unresponsive, so my rate goes down to 1Mb/s immediately. Then I have to wait for some minutes until the statistics have recovered enough for the rate control to raise the rate. Of course it goes straight through the roof to 54Mb/s. Errors accumulate, and soon I'm back at 1Mb/s. And so on.

My patch changes the way the average of failed frames is computed. By using a moving average approach, old values don't influence the estimate after some time (note the current approach always uses the plain counters, thus using all information accumulated since the interface has been brought up!). This makes the estimate more responsive and thus the rate control algorithm works a lot better.

I've tested my approach by listening to web radio for some time and it successfully keeps me between around 24Mb/s and 54Mb/s. From what I see here, that's a big improvement over the roller coaster rate control behaviour I had before.

Mattias