All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH] mac80211: Use PID controller for TX rate control
@ 2007-12-02 19:05 Mattias Nissler
  2007-12-03  3:16 ` Stefano Brivio
  0 siblings, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-02 19:05 UTC (permalink / raw)
  To: Stefano Brivio; +Cc: linux-wireless, John W. Linville, Johannes Berg

Hi,

the patch below is a first attempt on the PID-controller approach for TX
rate control. It kind of works here, but I haven't spent much time
tuning the coefficients.

I wanted to share this at this early stage so you can experiment with
and comment.

Mattias


Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
---
 net/mac80211/ieee80211_rate.h |    3 -
 net/mac80211/rc80211_simple.c |  281 ++++++++++++++++++++++++++++-------------
 2 files changed, 190 insertions(+), 94 deletions(-)

diff --git a/net/mac80211/ieee80211_rate.h b/net/mac80211/ieee80211_rate.h
index 2368813..9948d0f 100644
--- a/net/mac80211/ieee80211_rate.h
+++ b/net/mac80211/ieee80211_rate.h
@@ -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: */
diff --git a/net/mac80211/rc80211_simple.c b/net/mac80211/rc80211_simple.c
index da72737..af6f8ff 100644
--- a/net/mac80211/rc80211_simple.c
+++ b/net/mac80211/rc80211_simple.c
@@ -20,52 +20,127 @@
 #include "debugfs.h"
 

-/* This is a minimal implementation of TX rate controlling that can be used
- * as the default when no improved mechanisms are available. */
+/* This is an implementation of TX rate control algorithm that uses a PID
+ * controller. Given a target failed frames rate, the controller decides about
+ * TX rate changes to meet the target failed frames rate.
+ *
+ * The controller basically computes the following:
+ *
+ * adj = CP * err + CI * err_avg + CD * (err - last_err)
+ *
+ * where
+ * 	adj	adjustment value that is used to switch TX rate (see below)
+ * 	err	current error: target vs. current failed frames percentage
+ * 	last_err	last error
+ * 	err_avg	average (i.e. poor man's integral) of recent errors
+ * 	CP	Proportional coefficient
+ * 	CI	Integral coefficient
+ * 	CD	Derivative coefficient
+ *
+ * CP, CI, CD are subject to careful tuning.
+ *
+ * The integral component uses a exponential moving average approach instead of
+ * an actual sliding window. Advantage is that we don't need to keep an array of
+ * the last N error values and computation is easier.
+ *
+ * Once we have the adj value, we need to map it to a TX rate to be selected.
+ * For now, we depend on the rates to be ordered in a way such that more robust
+ * rates (i.e. such that exhibit a lower framed failed percentage) come first.
+ * E.g. for the 802.11b/g case, we first have the b rates in ascending order,
+ * then the g rates. The adj simply decides the index of the TX rate in the list
+ * to switch to (relative to the current TX rate entry).
+ *
+ * Note that for the computations we use a fixed-point representation to avoid
+ * floating point arithmetic. Hence, all values are shifted left by
+ * RATE_CONTROL_ARITH_SHIFT.
+ */
 
+/* Sampling frequency for measuring percentage of failed frames. */
+#define RATE_CONTROL_INTERVAL (HZ / 1)
 
-#define RATE_CONTROL_EMERG_DEC 2
-#define RATE_CONTROL_INTERVAL (HZ / 20)
-#define RATE_CONTROL_MIN_TX 10
+/* Exponential averaging smoothness (used for I part of PID controller) */
+#define RATE_CONTROL_SMOOTHING_SHIFT 3
+#define RATE_CONTROL_SMOOTHING (1 << RATE_CONTROL_SMOOTHING_SHIFT)
 
-static void rate_control_rate_inc(struct ieee80211_local *local,
-				  struct sta_info *sta)
-{
-	struct ieee80211_sub_if_data *sdata;
-	struct ieee80211_hw_mode *mode;
-	int i = sta->txrate;
-	int maxrate;
+/* Fixed point arithmetic shifting amount. */
+#define RATE_CONTROL_ARITH_SHIFT 8
 
-	sdata = IEEE80211_DEV_TO_SUB_IF(sta->dev);
-	if (sdata->bss && sdata->bss->force_unicast_rateidx > -1) {
-		/* forced unicast rate - do not change STA rate */
-		return;
-	}
+/* Fixed point arithmetic factor. */
+#define RATE_CONTROL_ARITH_FACTOR (1 << RATE_CONTROL_ARITH_SHIFT)
 
-	mode = local->oper_hw_mode;
-	maxrate = sdata->bss ? sdata->bss->max_ratectrl_rateidx : -1;
+/* Proportional PID component coefficient. */
+#define RATE_CONTROL_COEFF_P 15
+/* Integral PID component coefficient. */
+#define RATE_CONTROL_COEFF_I 10
+/* Derivative PID component coefficient. */
+#define RATE_CONTROL_COEFF_D 15
 
-	if (i > mode->num_rates)
-		i = mode->num_rates - 2;
+/* Target failed frames rate for the PID controller. NB: This effectively gives
+ * maximum failed frames percentage we're willing to accept. If communication is
+ * good, the controller will fail to adjust failed frames percentage to the
+ * target. This is intentional.
+ */
+#define RATE_CONTROL_TARGET_PF (20 << RATE_CONTROL_ARITH_SHIFT)
 
-	while (i + 1 < mode->num_rates) {
-		i++;
-		if (sta->supp_rates & BIT(i) &&
-		    mode->rates[i].flags & IEEE80211_RATE_SUPPORTED &&
-		    (maxrate < 0 || i <= maxrate)) {
-			sta->txrate = i;
-			break;
-		}
-	}
-}
+struct sta_rate_control {
+	unsigned long last_change;
+	unsigned long last_sample;
 
+	u32 tx_num_failed;
+	u32 tx_num_xmit;
 
-static void rate_control_rate_dec(struct ieee80211_local *local,
-				  struct sta_info *sta)
+	/*
+	 * Average failed frames percentage error (i.e. actual vs. target
+	 * percentage), scaled by RATE_CONTROL_SMOOTHING. This value is a
+	 * smoothed by using a exponentail weighted average technique:
+	 *
+	 *           (SMOOTHING - 1) * err_avg_old + err
+	 * err_avg = -----------------------------------
+	 *                       SMOOTHING
+	 *
+	 * where err_avg is the new approximation, err_avg_old the previous one
+	 * and err is the error w.r.t. to the current failed frames percentage
+	 * sample. Note that the bigger SMOOTHING the more weight is given to
+	 * the previous estimate, resulting in smoother behavior (i.e.
+	 * corresponding to a longer integration window).
+	 *
+	 * For computation, we actually don't use the above formula, but this
+	 * one:
+	 *
+	 * err_avg_scaled = err_avg_old_scaled - err_avg_old + err
+	 *
+	 * where:
+	 * 	err_avg_scaled = err * SMOOTHING
+	 * 	err_avg_old_scaled = err_avg_old * SMOOTHING
+	 *
+	 * This avoids floating point numbers and the per_failed_old value can
+	 * easily be obtained by shifting per_failed_old_scaled right by
+	 * RATE_CONTROL_SMOOTHING_SHIFT.
+	 */
+	s32 err_avg_sc;
+
+	/* Last framed failes percentage sample */
+	u32 last_pf;
+
+	unsigned long avg_rate_update;
+	u32 tx_avg_rate_sum;
+	u32 tx_avg_rate_num;
+
+#ifdef CONFIG_MAC80211_DEBUGFS
+	struct dentry *tx_avg_rate_sum_dentry;
+	struct dentry *tx_avg_rate_num_dentry;
+#endif
+};
+
+
+static void rate_control_adjust_rate(struct ieee80211_local *local,
+				     struct sta_info *sta, int adj)
 {
 	struct ieee80211_sub_if_data *sdata;
 	struct ieee80211_hw_mode *mode;
-	int i = sta->txrate;
+	int newidx = sta->txrate + adj;
+	int maxrate;
+	int back = (adj > 0) ? 1 : -1;
 
 	sdata = IEEE80211_DEV_TO_SUB_IF(sta->dev);
 	if (sdata->bss && sdata->bss->force_unicast_rateidx > -1) {
@@ -74,20 +149,29 @@ static void rate_control_rate_dec(struct ieee80211_local *local,
 	}
 
 	mode = local->oper_hw_mode;
-	if (i > mode->num_rates)
-		i = mode->num_rates;
+	maxrate = sdata->bss ? sdata->bss->max_ratectrl_rateidx : -1;
+
+	if (newidx < 0)
+		newidx = 0;
+	else if (newidx >= mode->num_rates)
+		newidx = mode->num_rates - 1;
+
+	while (newidx != sta->txrate) {
+		if (sta->supp_rates & BIT(newidx) &&
+		    mode->rates[newidx].flags & IEEE80211_RATE_SUPPORTED &&
+		    (maxrate < 0 || newidx <= maxrate)) {
+			sta->txrate = newidx;
+
+			printk(KERN_DEBUG "rate_control: new tx rate %d\n",
+			       mode->rates[newidx].rate);
 
-	while (i > 0) {
-		i--;
-		if (sta->supp_rates & BIT(i) &&
-		    mode->rates[i].flags & IEEE80211_RATE_SUPPORTED) {
-			sta->txrate = i;
 			break;
 		}
+
+		newidx += back;
 	}
 }
 
-
 static struct ieee80211_rate *
 rate_control_lowest_rate(struct ieee80211_local *local,
 			 struct ieee80211_hw_mode *mode)
@@ -111,22 +195,6 @@ struct global_rate_control {
 	int dummy;
 };
 
-struct sta_rate_control {
-	unsigned long last_rate_change;
-	u32 tx_num_failures;
-	u32 tx_num_xmit;
-
-	unsigned long avg_rate_update;
-	u32 tx_avg_rate_sum;
-	u32 tx_avg_rate_num;
-
-#ifdef CONFIG_MAC80211_DEBUGFS
-	struct dentry *tx_avg_rate_sum_dentry;
-	struct dentry *tx_avg_rate_num_dentry;
-#endif
-};
-
-
 static void rate_control_simple_tx_status(void *priv, struct net_device *dev,
 					  struct sk_buff *skb,
 					  struct ieee80211_tx_status *status)
@@ -143,8 +211,20 @@ static void rate_control_simple_tx_status(void *priv, struct net_device *dev,
 
 	srctrl = sta->rate_ctrl_priv;
 	srctrl->tx_num_xmit++;
+
+	/* We count frames that totally failed to be transmitted as two bad
+	 * frames, those that made it out but had some retries as one good and
+	 * one bad frame.
+	 */
+	if (status->excessive_retries) {
+		srctrl->tx_num_failed += 2;
+		srctrl->tx_num_xmit++;
+	} else if (status->retry_count) {
+		srctrl->tx_num_failed++;
+		srctrl->tx_num_xmit++;
+	}
+
 	if (status->excessive_retries) {
-		srctrl->tx_num_failures++;
 		sta->tx_retry_failed++;
 		sta->tx_num_consecutive_failures++;
 		sta->tx_num_mpdu_fail++;
@@ -158,40 +238,59 @@ static void rate_control_simple_tx_status(void *priv, struct net_device *dev,
 	sta->tx_retry_count += status->retry_count;
 	sta->tx_num_mpdu_fail += status->retry_count;
 
-	if (time_after(jiffies,
-		       srctrl->last_rate_change + RATE_CONTROL_INTERVAL) &&
-		srctrl->tx_num_xmit > RATE_CONTROL_MIN_TX) {
-		u32 per_failed;
-		srctrl->last_rate_change = jiffies;
-
-		per_failed = (100 * sta->tx_num_mpdu_fail) /
-			(sta->tx_num_mpdu_fail + sta->tx_num_mpdu_ok);
-		/* TODO: calculate average per_failed to make adjusting
-		 * parameters easier */
-#if 0
-		if (net_ratelimit()) {
-			printk(KERN_DEBUG "MPDU fail=%d ok=%d per_failed=%d\n",
-			       sta->tx_num_mpdu_fail, sta->tx_num_mpdu_ok,
-			       per_failed);
-		}
-#endif
-
-		/*
-		 * XXX: Make these configurable once we have an
-		 * interface to the rate control algorithms
+	/*
+	 * Update PID controller state.
+	 */
+	if (time_after(jiffies, srctrl->last_sample + RATE_CONTROL_INTERVAL)) {
+		u32 pf;
+		s32 err_avg;
+		s32 err_prop;
+		s32 err_int;
+		s32 err_der;
+		int adj;
+
+		srctrl->last_sample = jiffies;
+
+		/* If no frames were transmitted, we assume the old sample is
+		 * still a good measurement and copy it.
 		 */
-		if (per_failed > RATE_CONTROL_NUM_DOWN) {
-			rate_control_rate_dec(local, sta);
-		} else if (per_failed < RATE_CONTROL_NUM_UP) {
-			rate_control_rate_inc(local, sta);
+		if (srctrl->tx_num_xmit == 0)
+			pf = srctrl->last_pf;
+		else {
+			pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
+			pf <<= RATE_CONTROL_ARITH_SHIFT;
+
+			srctrl->tx_num_xmit = 0;
+			srctrl->tx_num_failed = 0;
 		}
-		srctrl->tx_avg_rate_sum += status->control.rate->rate;
-		srctrl->tx_avg_rate_num++;
-		srctrl->tx_num_failures = 0;
-		srctrl->tx_num_xmit = 0;
-	} else if (sta->tx_num_consecutive_failures >=
-		   RATE_CONTROL_EMERG_DEC) {
-		rate_control_rate_dec(local, sta);
+
+		/* Compute the proportional, integral and derivative errors. */
+		err_prop = RATE_CONTROL_TARGET_PF - pf;
+
+		err_avg = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
+		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
+		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
+
+		err_der = pf - srctrl->last_pf;
+		srctrl->last_pf = pf;
+
+		/* Compute the controller output. */
+		adj = (err_prop * RATE_CONTROL_COEFF_P
+		      + err_int * RATE_CONTROL_COEFF_I
+		      + err_der * RATE_CONTROL_COEFF_D)
+			>> (2 * RATE_CONTROL_ARITH_SHIFT);
+
+		printk(KERN_DEBUG "rate_control: sample %d "
+		       "err_prop %d err_int %d err_der %d adj %d\n",
+		       pf >> RATE_CONTROL_ARITH_SHIFT,
+		       err_prop >> RATE_CONTROL_ARITH_SHIFT,
+		       err_int >> RATE_CONTROL_ARITH_SHIFT,
+		       err_der >> RATE_CONTROL_ARITH_SHIFT,
+		       adj);
+
+		/* Change rate. */
+		if (adj)
+			rate_control_adjust_rate(local, sta, adj);
 	}
 
 	if (srctrl->avg_rate_update + 60 * HZ < jiffies) {
-- 
1.5.3.4


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-02 19:05 [RFC][PATCH] mac80211: Use PID controller for TX rate control Mattias Nissler
@ 2007-12-03  3:16 ` Stefano Brivio
  2007-12-03  3:26   ` Stefano Brivio
  2007-12-03 11:03   ` Mattias Nissler
  0 siblings, 2 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-03  3:16 UTC (permalink / raw)
  To: Mattias Nissler; +Cc: linux-wireless, John W. Linville, Johannes Berg

On Sun, 02 Dec 2007 20:05:31 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> Hi,
> 
> the patch below is a first attempt on the PID-controller approach for TX
> rate control. It kind of works here, but I haven't spent much time
> tuning the coefficients.

It looks good! I tested it a bit with different TX powers and moving around
with a microwave oven turned on [1]. It looks like we don't have the
rollercoaster effect anymore, and overall quality of the algorithm seems
just fine. However, I noticed about two issues:

1) as soon as I loaded mac80211 it took a lot of time to get up with rate,
and this actually happens every time I'm not sending frames for a while
(including get down with rate here).
	- IMHO, it doesn't make sense to check for RSSI of previous packets
as soon as we get associated, because it's very likely that we just switched
between two APs.
	- Here, either we know that something happened (such an association)
and we need to react quite quickly, either we don't know what's happening
and relying solely on interpolation seems not to work so well.
So I thought rather of a "sharpening" factor to be taken into account
when some important events (i.e. association) or interpolation happened.
This seems to work quite well, so in perfect conditions and average load I
need ~6 seconds vs ~11 to get up to 54M, while still maintaining smoothness
during regular operation (thus it looks like there aren't rollercoasting
risks - obviously this will need more testing):
[this patch applies on top of yours]

Index: wireless-2.6/net/mac80211/rc80211_simple.c
===================================================================
--- wireless-2.6.orig/net/mac80211/rc80211_simple.c
+++ wireless-2.6/net/mac80211/rc80211_simple.c
@@ -26,13 +26,15 @@
  *
  * The controller basically computes the following:
  *
- * adj = CP * err + CI * err_avg + CD * (err - last_err)
+ * adj = CP * err + CI * err_avg + CD * (1 + sharpening) * (err - last_err)
  *
  * where
  * 	adj	adjustment value that is used to switch TX rate (see below)
  * 	err	current error: target vs. current failed frames percentage
  * 	last_err	last error
  * 	err_avg	average (i.e. poor man's integral) of recent errors
+ *	sharpening	non-zero when fast response is needed (i.e. right after
+ *			association or interpolation)
  * 	CP	Proportional coefficient
  * 	CI	Integral coefficient
  * 	CD	Derivative coefficient
@@ -62,6 +64,11 @@
 #define RATE_CONTROL_SMOOTHING_SHIFT 3
 #define RATE_CONTROL_SMOOTHING (1 << RATE_CONTROL_SMOOTHING_SHIFT)
 
+/* Sharpening factor (used for D part of PID controller) */
+#define RATE_CONTROL_SHARPENING_SHIFT 2
+#define RATE_CONTROL_SHARPENING (1 << RATE_CONTROL_SHARPENING_SHIFT)
+#define RATE_CONTROL_SHARPENING_DURATION 3
+
 /* Fixed point arithmetic shifting amount. */
 #define RATE_CONTROL_ARITH_SHIFT 8
 
@@ -122,6 +129,9 @@ struct sta_rate_control {
 	/* Last framed failes percentage sample */
 	u32 last_pf;
 
+	/* Sharpening needed */
+	u8 sharp_cnt;
+
 	unsigned long avg_rate_update;
 	u32 tx_avg_rate_sum;
 	u32 tx_avg_rate_num;
@@ -252,10 +262,12 @@ static void rate_control_simple_tx_statu
 		srctrl->last_sample = jiffies;
 
 		/* If no frames were transmitted, we assume the old sample is
-		 * still a good measurement and copy it.
+		 * still a good measurement and copy it, and turn the
+		 * sharpening factor on.
 		 */
-		if (srctrl->tx_num_xmit == 0)
+		if (srctrl->tx_num_xmit == 0) {
 			pf = srctrl->last_pf;
+			srctrl->sharp_cnt = RATE_CONTROL_SHARPENING_DURATION;
 		else {
 			pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
 			pf <<= RATE_CONTROL_ARITH_SHIFT;
@@ -271,8 +283,11 @@ static void rate_control_simple_tx_statu
 		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
 		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
 
-		err_der = pf - srctrl->last_pf;
+		err_der = pf - srctrl->last_pf
+			  + RATE_CONTROL_SHARPENING * srctrl->sharp;
 		srctrl->last_pf = pf;
+		if (srctrl->sharp)
+			srctrl->sharp--;
 
 		/* Compute the controller output. */
 		adj = (err_prop * RATE_CONTROL_COEFF_P


2) It seems that most of the devices out there have better sensitivity at 6
and 9M than at 11M, while others haven't, e.g.:
Rate [Mbps]	Sensitivity [dBm]
	(1)	(2)	(3)	(4)
1	-97	-91	-90	-96
2	-96		-90	-95
5.5	-95		-86	-94
11	-92	-88	-82	-94
6	-94	-85	-90	-91
9	-93		-89	-90
12	-91		-86	-88
18	-90		-82	-86
24	-86		-79	-83
36	-83		-76	-78
48	-77		-72	-76
54	-74	-69	-72	-75

(1) Ubiquiti SR2, Atheros-based
(2) Marvell 88W8686 SM module
(3) Cheap Atheros based access point
(4) Cheap Broadcom 4318E device

So, I guess we can't think of a preset ordering for rates. I tested this
with a Broadcom based device (which should be pretty similar to (4)), but the
only other wireless card which supports both 802.11b and 802.11g I got is
an Intel IPW2200 (which is not supported by any mac80211 driver). So,
testing this with an Atheros, e.g., or some new Intel device, could lead to
unexpected behaviour and thus we may need to keep some table like: rate <->
recent failed frames. But we would really need more testers here!

I'll try to provide more comments and tuning in a few days.


[1] Always remember: put at least 20cc (426 U.S. microbarrels) of water in
the microwave oven before turning it on. Failing to do so could cause kitchen
regressions.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03  3:16 ` Stefano Brivio
@ 2007-12-03  3:26   ` Stefano Brivio
  2007-12-03 11:03   ` Mattias Nissler
  1 sibling, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-03  3:26 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Mattias Nissler, linux-wireless, John W. Linville, Johannes Berg

Sorry, it looks like I didn't refresh the patch I just inlined:

Index: wireless-2.6/net/mac80211/rc80211_simple.c
===================================================================
--- wireless-2.6.orig/net/mac80211/rc80211_simple.c
+++ wireless-2.6/net/mac80211/rc80211_simple.c
@@ -26,13 +26,15 @@
  *
  * The controller basically computes the following:
  *
- * adj = CP * err + CI * err_avg + CD * (err - last_err)
+ * adj = CP * err + CI * err_avg + CD * (1 + sharpening) * (err - last_err)
  *
  * where
  * 	adj	adjustment value that is used to switch TX rate (see below)
  * 	err	current error: target vs. current failed frames percentage
  * 	last_err	last error
  * 	err_avg	average (i.e. poor man's integral) of recent errors
+ *	sharpening	non-zero when fast response is needed (i.e. right after
+ *			association or interpolation)
  * 	CP	Proportional coefficient
  * 	CI	Integral coefficient
  * 	CD	Derivative coefficient
@@ -62,6 +64,11 @@
 #define RATE_CONTROL_SMOOTHING_SHIFT 3
 #define RATE_CONTROL_SMOOTHING (1 << RATE_CONTROL_SMOOTHING_SHIFT)
 
+/* Sharpening factor (used for D part of PID controller) */
+#define RATE_CONTROL_SHARPENING_SHIFT 2
+#define RATE_CONTROL_SHARPENING (1 << RATE_CONTROL_SHARPENING_SHIFT)
+#define RATE_CONTROL_SHARPENING_DURATION 3
+
 /* Fixed point arithmetic shifting amount. */
 #define RATE_CONTROL_ARITH_SHIFT 8
 
@@ -122,6 +129,9 @@ struct sta_rate_control {
 	/* Last framed failes percentage sample */
 	u32 last_pf;
 
+	/* Sharpening needed */
+	u8 sharp_cnt;
+
 	unsigned long avg_rate_update;
 	u32 tx_avg_rate_sum;
 	u32 tx_avg_rate_num;
@@ -252,11 +262,13 @@ static void rate_control_simple_tx_statu
 		srctrl->last_sample = jiffies;
 
 		/* If no frames were transmitted, we assume the old sample is
-		 * still a good measurement and copy it.
+		 * still a good measurement and copy it, and turn the
+		 * sharpening factor on.
 		 */
-		if (srctrl->tx_num_xmit == 0)
+		if (srctrl->tx_num_xmit == 0) {
 			pf = srctrl->last_pf;
-		else {
+			srctrl->sharp_cnt = RATE_CONTROL_SHARPENING_DURATION;
+		} else {
 			pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
 			pf <<= RATE_CONTROL_ARITH_SHIFT;
 
@@ -271,8 +283,11 @@ static void rate_control_simple_tx_statu
 		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
 		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
 
-		err_der = pf - srctrl->last_pf;
+		err_der = (pf - srctrl->last_pf) *
+			  (1 + RATE_CONTROL_SHARPENING * srctrl->sharp_cnt);
 		srctrl->last_pf = pf;
+		if (srctrl->sharp_cnt)
+			srctrl->sharp_cnt--;
 
 		/* Compute the controller output. */
 		adj = (err_prop * RATE_CONTROL_COEFF_P


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03  3:16 ` Stefano Brivio
  2007-12-03  3:26   ` Stefano Brivio
@ 2007-12-03 11:03   ` Mattias Nissler
  2007-12-03 11:21     ` Tomas Winkler
  2007-12-03 11:54     ` Stefano Brivio
  1 sibling, 2 replies; 34+ messages in thread
From: Mattias Nissler @ 2007-12-03 11:03 UTC (permalink / raw)
  To: Stefano Brivio; +Cc: linux-wireless, John W. Linville, Johannes Berg


On Mon, 2007-12-03 at 04:16 +0100, Stefano Brivio wrote:
> On Sun, 02 Dec 2007 20:05:31 +0100
> Mattias Nissler <mattias.nissler@gmx.de> wrote:
> 
> > Hi,
> > 
> > the patch below is a first attempt on the PID-controller approach for TX
> > rate control. It kind of works here, but I haven't spent much time
> > tuning the coefficients.
> 
> It looks good! I tested it a bit with different TX powers and moving around
> with a microwave oven turned on [1]. It looks like we don't have the
> rollercoaster effect anymore, and overall quality of the algorithm seems
> just fine. However, I noticed about two issues:
> 
> 1) as soon as I loaded mac80211 it took a lot of time to get up with rate,
> and this actually happens every time I'm not sending frames for a while
> (including get down with rate here).
> 	- IMHO, it doesn't make sense to check for RSSI of previous packets
> as soon as we get associated, because it's very likely that we just switched
> between two APs.

Wait a sec. Rate control is per station, so each AP will have it's own
rate control state.

> 	- Here, either we know that something happened (such an association)
> and we need to react quite quickly, either we don't know what's happening
> and relying solely on interpolation seems not to work so well.
> So I thought rather of a "sharpening" factor to be taken into account
> when some important events (i.e. association) or interpolation happened.
> This seems to work quite well, so in perfect conditions and average load I
> need ~6 seconds vs ~11 to get up to 54M, while still maintaining smoothness
> during regular operation (thus it looks like there aren't rollercoasting
> risks - obviously this will need more testing):

Have you tried shorter sample intervals? Currently, it's once per
second. I plan to shorten it, maybe to 2Hz or even 4Hz and see whether
we can get better responsiveness and still stay stable. Also, the
integration time needs to be fine-tuned then.

> [this patch applies on top of yours]
> 
> Index: wireless-2.6/net/mac80211/rc80211_simple.c
> ===================================================================
> --- wireless-2.6.orig/net/mac80211/rc80211_simple.c
> +++ wireless-2.6/net/mac80211/rc80211_simple.c
> @@ -26,13 +26,15 @@
>   *
>   * The controller basically computes the following:
>   *
> - * adj = CP * err + CI * err_avg + CD * (err - last_err)
> + * adj = CP * err + CI * err_avg + CD * (1 + sharpening) * (err - last_err)
>   *
>   * where
>   * 	adj	adjustment value that is used to switch TX rate (see below)
>   * 	err	current error: target vs. current failed frames percentage
>   * 	last_err	last error
>   * 	err_avg	average (i.e. poor man's integral) of recent errors
> + *	sharpening	non-zero when fast response is needed (i.e. right after
> + *			association or interpolation)
>   * 	CP	Proportional coefficient
>   * 	CI	Integral coefficient
>   * 	CD	Derivative coefficient
> @@ -62,6 +64,11 @@
>  #define RATE_CONTROL_SMOOTHING_SHIFT 3
>  #define RATE_CONTROL_SMOOTHING (1 << RATE_CONTROL_SMOOTHING_SHIFT)
>  
> +/* Sharpening factor (used for D part of PID controller) */
> +#define RATE_CONTROL_SHARPENING_SHIFT 2
> +#define RATE_CONTROL_SHARPENING (1 << RATE_CONTROL_SHARPENING_SHIFT)
> +#define RATE_CONTROL_SHARPENING_DURATION 3
> +
>  /* Fixed point arithmetic shifting amount. */
>  #define RATE_CONTROL_ARITH_SHIFT 8
>  
> @@ -122,6 +129,9 @@ struct sta_rate_control {
>  	/* Last framed failes percentage sample */
>  	u32 last_pf;
>  
> +	/* Sharpening needed */
> +	u8 sharp_cnt;
> +
>  	unsigned long avg_rate_update;
>  	u32 tx_avg_rate_sum;
>  	u32 tx_avg_rate_num;
> @@ -252,10 +262,12 @@ static void rate_control_simple_tx_statu
>  		srctrl->last_sample = jiffies;
>  
>  		/* If no frames were transmitted, we assume the old sample is
> -		 * still a good measurement and copy it.
> +		 * still a good measurement and copy it, and turn the
> +		 * sharpening factor on.
>  		 */
> -		if (srctrl->tx_num_xmit == 0)
> +		if (srctrl->tx_num_xmit == 0) {
>  			pf = srctrl->last_pf;
> +			srctrl->sharp_cnt = RATE_CONTROL_SHARPENING_DURATION;
>  		else {
>  			pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
>  			pf <<= RATE_CONTROL_ARITH_SHIFT;
> @@ -271,8 +283,11 @@ static void rate_control_simple_tx_statu
>  		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
>  		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
>  
> -		err_der = pf - srctrl->last_pf;
> +		err_der = pf - srctrl->last_pf
> +			  + RATE_CONTROL_SHARPENING * srctrl->sharp;
>  		srctrl->last_pf = pf;
> +		if (srctrl->sharp)
> +			srctrl->sharp--;
>  
>  		/* Compute the controller output. */
>  		adj = (err_prop * RATE_CONTROL_COEFF_P
> 
> 
> 2) It seems that most of the devices out there have better sensitivity at 6
> and 9M than at 11M, while others haven't, e.g.:
> Rate [Mbps]	Sensitivity [dBm]
> 	(1)	(2)	(3)	(4)
> 1	-97	-91	-90	-96
> 2	-96		-90	-95
> 5.5	-95		-86	-94
> 11	-92	-88	-82	-94
> 6	-94	-85	-90	-91
> 9	-93		-89	-90
> 12	-91		-86	-88
> 18	-90		-82	-86
> 24	-86		-79	-83
> 36	-83		-76	-78
> 48	-77		-72	-76
> 54	-74	-69	-72	-75
> 
> (1) Ubiquiti SR2, Atheros-based
> (2) Marvell 88W8686 SM module
> (3) Cheap Atheros based access point
> (4) Cheap Broadcom 4318E device
> 
> So, I guess we can't think of a preset ordering for rates. I tested this
> with a Broadcom based device (which should be pretty similar to (4)), but the
> only other wireless card which supports both 802.11b and 802.11g I got is
> an Intel IPW2200 (which is not supported by any mac80211 driver). So,
> testing this with an Atheros, e.g., or some new Intel device, could lead to
> unexpected behaviour and thus we may need to keep some table like: rate <->
> recent failed frames.

Hm, from your table above, there doesn't seem to be a significant
problem with the 6 and 9 OFDM rates. We could also just leave them out
and go to 12Mbps OFDM from 11Mbps CCK.

I also thought about your rate <-> failed frames table. I'm not
convinced this works, because I cannot see a way to obtain consistent
values for the table. Clearly, measuring table entries should be done
with equal interference conditions for all entries, and they must also
be adjusted over time. However, if we only collect data during normal
operation, we'll likely have good data only for the few recent rates we
were operating at.

>  But we would really need more testers here!

Indeed :-)

> 
> I'll try to provide more comments and tuning in a few days.

Great!

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:03   ` Mattias Nissler
@ 2007-12-03 11:21     ` Tomas Winkler
  2007-12-03 11:31       ` Mattias Nissler
  2007-12-03 11:58       ` Stefano Brivio
  2007-12-03 11:54     ` Stefano Brivio
  1 sibling, 2 replies; 34+ messages in thread
From: Tomas Winkler @ 2007-12-03 11:21 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Stefano Brivio, linux-wireless, John W. Linville, Johannes Berg

A little suggestion, maybe instead of overriding the simple algorithm
you should create new let say pid_controler rate scale algorithm.  It
doesn't look simple anymore :)
Tomas

On Dec 3, 2007 1:03 PM, Mattias Nissler <mattias.nissler@gmx.de> wrote:
>
> On Mon, 2007-12-03 at 04:16 +0100, Stefano Brivio wrote:
> > On Sun, 02 Dec 2007 20:05:31 +0100
> > Mattias Nissler <mattias.nissler@gmx.de> wrote:
> >
> > > Hi,
> > >
> > > the patch below is a first attempt on the PID-controller approach for TX
> > > rate control. It kind of works here, but I haven't spent much time
> > > tuning the coefficients.
> >
> > It looks good! I tested it a bit with different TX powers and moving around
> > with a microwave oven turned on [1]. It looks like we don't have the
> > rollercoaster effect anymore, and overall quality of the algorithm seems
> > just fine. However, I noticed about two issues:
> >
> > 1) as soon as I loaded mac80211 it took a lot of time to get up with rate,
> > and this actually happens every time I'm not sending frames for a while
> > (including get down with rate here).
> >       - IMHO, it doesn't make sense to check for RSSI of previous packets
> > as soon as we get associated, because it's very likely that we just switched
> > between two APs.
>
> Wait a sec. Rate control is per station, so each AP will have it's own
> rate control state.
>
> >       - Here, either we know that something happened (such an association)
> > and we need to react quite quickly, either we don't know what's happening
> > and relying solely on interpolation seems not to work so well.
> > So I thought rather of a "sharpening" factor to be taken into account
> > when some important events (i.e. association) or interpolation happened.
> > This seems to work quite well, so in perfect conditions and average load I
> > need ~6 seconds vs ~11 to get up to 54M, while still maintaining smoothness
> > during regular operation (thus it looks like there aren't rollercoasting
> > risks - obviously this will need more testing):
>
> Have you tried shorter sample intervals? Currently, it's once per
> second. I plan to shorten it, maybe to 2Hz or even 4Hz and see whether
> we can get better responsiveness and still stay stable. Also, the
> integration time needs to be fine-tuned then.
>
>
> > [this patch applies on top of yours]
> >
> > Index: wireless-2.6/net/mac80211/rc80211_simple.c
> > ===================================================================
> > --- wireless-2.6.orig/net/mac80211/rc80211_simple.c
> > +++ wireless-2.6/net/mac80211/rc80211_simple.c
> > @@ -26,13 +26,15 @@
> >   *
> >   * The controller basically computes the following:
> >   *
> > - * adj = CP * err + CI * err_avg + CD * (err - last_err)
> > + * adj = CP * err + CI * err_avg + CD * (1 + sharpening) * (err - last_err)
> >   *
> >   * where
> >   *   adj     adjustment value that is used to switch TX rate (see below)
> >   *   err     current error: target vs. current failed frames percentage
> >   *   last_err        last error
> >   *   err_avg average (i.e. poor man's integral) of recent errors
> > + *   sharpening      non-zero when fast response is needed (i.e. right after
> > + *                   association or interpolation)
> >   *   CP      Proportional coefficient
> >   *   CI      Integral coefficient
> >   *   CD      Derivative coefficient
> > @@ -62,6 +64,11 @@
> >  #define RATE_CONTROL_SMOOTHING_SHIFT 3
> >  #define RATE_CONTROL_SMOOTHING (1 << RATE_CONTROL_SMOOTHING_SHIFT)
> >
> > +/* Sharpening factor (used for D part of PID controller) */
> > +#define RATE_CONTROL_SHARPENING_SHIFT 2
> > +#define RATE_CONTROL_SHARPENING (1 << RATE_CONTROL_SHARPENING_SHIFT)
> > +#define RATE_CONTROL_SHARPENING_DURATION 3
> > +
> >  /* Fixed point arithmetic shifting amount. */
> >  #define RATE_CONTROL_ARITH_SHIFT 8
> >
> > @@ -122,6 +129,9 @@ struct sta_rate_control {
> >       /* Last framed failes percentage sample */
> >       u32 last_pf;
> >
> > +     /* Sharpening needed */
> > +     u8 sharp_cnt;
> > +
> >       unsigned long avg_rate_update;
> >       u32 tx_avg_rate_sum;
> >       u32 tx_avg_rate_num;
> > @@ -252,10 +262,12 @@ static void rate_control_simple_tx_statu
> >               srctrl->last_sample = jiffies;
> >
> >               /* If no frames were transmitted, we assume the old sample is
> > -              * still a good measurement and copy it.
> > +              * still a good measurement and copy it, and turn the
> > +              * sharpening factor on.
> >                */
> > -             if (srctrl->tx_num_xmit == 0)
> > +             if (srctrl->tx_num_xmit == 0) {
> >                       pf = srctrl->last_pf;
> > +                     srctrl->sharp_cnt = RATE_CONTROL_SHARPENING_DURATION;
> >               else {
> >                       pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
> >                       pf <<= RATE_CONTROL_ARITH_SHIFT;
> > @@ -271,8 +283,11 @@ static void rate_control_simple_tx_statu
> >               srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
> >               err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
> >
> > -             err_der = pf - srctrl->last_pf;
> > +             err_der = pf - srctrl->last_pf
> > +                       + RATE_CONTROL_SHARPENING * srctrl->sharp;
> >               srctrl->last_pf = pf;
> > +             if (srctrl->sharp)
> > +                     srctrl->sharp--;
> >
> >               /* Compute the controller output. */
> >               adj = (err_prop * RATE_CONTROL_COEFF_P
> >
> >
> > 2) It seems that most of the devices out there have better sensitivity at 6
> > and 9M than at 11M, while others haven't, e.g.:
> > Rate [Mbps]   Sensitivity [dBm]
> >       (1)     (2)     (3)     (4)
> > 1     -97     -91     -90     -96
> > 2     -96             -90     -95
> > 5.5   -95             -86     -94
> > 11    -92     -88     -82     -94
> > 6     -94     -85     -90     -91
> > 9     -93             -89     -90
> > 12    -91             -86     -88
> > 18    -90             -82     -86
> > 24    -86             -79     -83
> > 36    -83             -76     -78
> > 48    -77             -72     -76
> > 54    -74     -69     -72     -75
> >
> > (1) Ubiquiti SR2, Atheros-based
> > (2) Marvell 88W8686 SM module
> > (3) Cheap Atheros based access point
> > (4) Cheap Broadcom 4318E device
> >
> > So, I guess we can't think of a preset ordering for rates. I tested this
> > with a Broadcom based device (which should be pretty similar to (4)), but the
> > only other wireless card which supports both 802.11b and 802.11g I got is
> > an Intel IPW2200 (which is not supported by any mac80211 driver). So,
> > testing this with an Atheros, e.g., or some new Intel device, could lead to
> > unexpected behaviour and thus we may need to keep some table like: rate <->
> > recent failed frames.
>
> Hm, from your table above, there doesn't seem to be a significant
> problem with the 6 and 9 OFDM rates. We could also just leave them out
> and go to 12Mbps OFDM from 11Mbps CCK.
>
> I also thought about your rate <-> failed frames table. I'm not
> convinced this works, because I cannot see a way to obtain consistent
> values for the table. Clearly, measuring table entries should be done
> with equal interference conditions for all entries, and they must also
> be adjusted over time. However, if we only collect data during normal
> operation, we'll likely have good data only for the few recent rates we
> were operating at.
>
> >  But we would really need more testers here!
>
> Indeed :-)
>
> >
> > I'll try to provide more comments and tuning in a few days.
>
> Great!
>
> Mattias
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:21     ` Tomas Winkler
@ 2007-12-03 11:31       ` Mattias Nissler
  2007-12-04 13:40         ` Johannes Berg
  2007-12-03 11:58       ` Stefano Brivio
  1 sibling, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-03 11:31 UTC (permalink / raw)
  To: Tomas Winkler
  Cc: Stefano Brivio, linux-wireless, John W. Linville, Johannes Berg


On Mon, 2007-12-03 at 13:21 +0200, Tomas Winkler wrote:
> A little suggestion, maybe instead of overriding the simple algorithm
> you should create new let say pid_controler rate scale algorithm.  It
> doesn't look simple anymore :)

I already thought so. But the original "simple" algorithm is totally
broken in most cases. Well, maybe except the cases perfect situation ->
no tx failures -> full rate and bad situation -> lots of tx failures ->
lowest rate. IMHO, we should just get rid of the old simple algorithm.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:03   ` Mattias Nissler
  2007-12-03 11:21     ` Tomas Winkler
@ 2007-12-03 11:54     ` Stefano Brivio
  2007-12-03 11:59       ` Mattias Nissler
  1 sibling, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-03 11:54 UTC (permalink / raw)
  To: Mattias Nissler; +Cc: linux-wireless, John W. Linville, Johannes Berg

On Mon, 03 Dec 2007 12:03:00 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> Wait a sec. Rate control is per station, so each AP will have it's own
> rate control state.

Ah, right. So fixing the related TODO may make sense.

> Have you tried shorter sample intervals? Currently, it's once per
> second. I plan to shorten it, maybe to 2Hz or even 4Hz and see whether
> we can get better responsiveness and still stay stable. Also, the
> integration time needs to be fine-tuned then.

Well, the integration and control times are just fine. I mean, you can tune
them, but I wouldn't expect the result to be very different. I just think we
need some intervention when exceptional events occur. But if you decide to
fix that TODO, considering association an exceptional event wouldn't make
sense any longer. I've seen improvements after interpolation cycles too,
though.

> I also thought about your rate <-> failed frames table. I'm not
> convinced this works, because I cannot see a way to obtain consistent
> values for the table. Clearly, measuring table entries should be done
> with equal interference conditions for all entries, and they must also
> be adjusted over time. However, if we only collect data during normal
> operation, we'll likely have good data only for the few recent rates we
> were operating at.

Yes, that's exactly what I meant.


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:21     ` Tomas Winkler
  2007-12-03 11:31       ` Mattias Nissler
@ 2007-12-03 11:58       ` Stefano Brivio
  1 sibling, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-03 11:58 UTC (permalink / raw)
  To: Tomas Winkler
  Cc: Mattias Nissler, linux-wireless, John W. Linville, Johannes Berg

On Mon, 3 Dec 2007 13:21:21 +0200
"Tomas Winkler" <tomasw@gmail.com> wrote:

> A little suggestion, maybe instead of overriding the simple algorithm
> you should create new let say pid_controler rate scale algorithm.  It
> doesn't look simple anymore :)
> Tomas

Please, could you avoid top-posting and useless full quoting? Thank you.


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:54     ` Stefano Brivio
@ 2007-12-03 11:59       ` Mattias Nissler
  2007-12-03 12:06         ` Stefano Brivio
  0 siblings, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-03 11:59 UTC (permalink / raw)
  To: Stefano Brivio; +Cc: linux-wireless, John W. Linville, Johannes Berg


On Mon, 2007-12-03 at 12:54 +0100, Stefano Brivio wrote:
> On Mon, 03 Dec 2007 12:03:00 +0100
> Mattias Nissler <mattias.nissler@gmx.de> wrote:
> 
> > Wait a sec. Rate control is per station, so each AP will have it's own
> > rate control state.
> 
> Ah, right. So fixing the related TODO may make sense.

What TODO excactly are you talking about?

> 
> > Have you tried shorter sample intervals? Currently, it's once per
> > second. I plan to shorten it, maybe to 2Hz or even 4Hz and see whether
> > we can get better responsiveness and still stay stable. Also, the
> > integration time needs to be fine-tuned then.
> 
> Well, the integration and control times are just fine. I mean, you can tune
> them, but I wouldn't expect the result to be very different. I just think we
> need some intervention when exceptional events occur. But if you decide to
> fix that TODO, considering association an exceptional event wouldn't make
> sense any longer. I've seen improvements after interpolation cycles too,
> though.
> 
> > I also thought about your rate <-> failed frames table. I'm not
> > convinced this works, because I cannot see a way to obtain consistent
> > values for the table. Clearly, measuring table entries should be done
> > with equal interference conditions for all entries, and they must also
> > be adjusted over time. However, if we only collect data during normal
> > operation, we'll likely have good data only for the few recent rates we
> > were operating at.
> 
> Yes, that's exactly what I meant.

So? How to do it right?

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:59       ` Mattias Nissler
@ 2007-12-03 12:06         ` Stefano Brivio
  2007-12-03 22:42           ` Nick Kossifidis
  0 siblings, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-03 12:06 UTC (permalink / raw)
  To: Mattias Nissler; +Cc: linux-wireless, John W. Linville, Johannes Berg

On Mon, 03 Dec 2007 12:59:04 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> On Mon, 2007-12-03 at 12:54 +0100, Stefano Brivio wrote:
> > On Mon, 03 Dec 2007 12:03:00 +0100
> > Mattias Nissler <mattias.nissler@gmx.de> wrote:
> > 
> > > Wait a sec. Rate control is per station, so each AP will have it's own
> > > rate control state.
> > 
> > Ah, right. So fixing the related TODO may make sense.
> 
> What TODO excactly are you talking about?

In rate_control_simple_rate_init():
	/* TODO: This routine should consider using RSSI from previous packets
	 * as we need to have IEEE 802.1X auth succeed immediately after assoc..
	 * Until that method is implemented, we will use the lowest supported rate
	 * as a workaround, */

> > > I also thought about your rate <-> failed frames table. I'm not
> > > convinced this works, because I cannot see a way to obtain consistent
> > > values for the table. Clearly, measuring table entries should be done
> > > with equal interference conditions for all entries, and they must also
> > > be adjusted over time. However, if we only collect data during normal
> > > operation, we'll likely have good data only for the few recent rates
> > > we were operating at.
> > 
> > Yes, that's exactly what I meant.
> 
> So? How to do it right?

I'd say we need a keep an array with one element for each rate. The
elements would get updated after that we used that rate. Only the most
recent value would be kept in the array. The issue here is how to deal with
uninitialized values. We may need some preset coefficient or such.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 12:06         ` Stefano Brivio
@ 2007-12-03 22:42           ` Nick Kossifidis
  2007-12-03 23:36             ` Mattias Nissler
  2007-12-04  1:41             ` Stefano Brivio
  0 siblings, 2 replies; 34+ messages in thread
From: Nick Kossifidis @ 2007-12-03 22:42 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Mattias Nissler, linux-wireless, John W. Linville, Johannes Berg

Here are some tests with ath5k + your patches...

I've tested a 5213 and a 5413 card, both have poor phy performance (we
still work on phy initialization,  txpower etc) that means they
receive ok but they can't transmit well (with other supported cards
i've got much better performance up to 27Mbits/sec but i didn't have
one in hand while testing, if you want i can repeat the test).

I've run iperf on the previous rate control, the patched one and with
locked tx rate.

5413 - pid
----------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 36143
[  3]  0.0- 1.0 sec    132 KBytes  1.08 Mbits/sec  7.021 ms   42/  134 (31%)
[  3]  1.0- 2.0 sec  50.2 KBytes    412 Kbits/sec  3.412 ms    0/   35 (0%)
[  3]  2.0- 3.0 sec  1.32 MBytes  11.0 Mbits/sec  1.379 ms  199/ 1138 (17%)
[  3]  3.0- 4.0 sec    224 KBytes  1.83 Mbits/sec  15.208 ms    0/  156 (0%)
[  3]  4.0- 5.0 sec    210 KBytes  1.72 Mbits/sec  10.241 ms    0/  146 (0%)
[  3]  5.0- 6.0 sec    425 KBytes  3.48 Mbits/sec  4.256 ms    0/  296 (0%)
[  3]  6.0- 7.0 sec    802 KBytes  6.57 Mbits/sec  2.843 ms    0/  559 (0%)
[  3]  7.0- 8.0 sec  1.13 MBytes  9.49 Mbits/sec  1.782 ms    0/  807 (0%)
[  3]  8.0- 9.0 sec  1.59 MBytes  13.3 Mbits/sec  1.661 ms    0/ 1132 (0%)
[  3]  9.0-10.0 sec  1.02 MBytes  8.58 Mbits/sec  1.776 ms    3/  733 (0.41%)
[  3] 10.0-11.0 sec  48.8 KBytes    400 Kbits/sec  1.808 ms    0/   34 (0%)
[  3] 11.0-12.0 sec  0.00 Bytes  0.00 bits/sec  1.808 ms    0/    0 (nan%)
[  3] 12.0-13.0 sec    647 KBytes  5.30 Mbits/sec  2.723 ms  429/  880 (49%)
[  3] 13.0-14.0 sec    162 KBytes  1.33 Mbits/sec  37.721 ms    0/  113 (0%)
[  3] 14.0-15.0 sec    108 KBytes    882 Kbits/sec  28.504 ms    0/   75 (0%)
[  3] 15.0-16.0 sec    139 KBytes  1.14 Mbits/sec  24.509 ms    0/   97 (0%)
[  3] 16.0-17.0 sec    395 KBytes  3.23 Mbits/sec  4.657 ms    0/  275 (0%)
[  3] 17.0-18.0 sec    805 KBytes  6.60 Mbits/sec  2.768 ms    0/  561 (0%)
[  3] 18.0-19.0 sec  1.12 MBytes  9.38 Mbits/sec  1.708 ms    0/  798 (0%)
[  3] 19.0-20.0 sec  1.56 MBytes  13.1 Mbits/sec  1.504 ms    0/ 1116 (0%)
[  3] 20.0-21.0 sec  1.11 MBytes  9.28 Mbits/sec  1.806 ms    0/  789 (0%)
[  3] 21.0-22.0 sec  64.6 KBytes    529 Kbits/sec  1.639 ms    0/   45 (0%)
[  3] 22.0-23.0 sec  0.00 Bytes  0.00 bits/sec  1.639 ms    0/    0 (nan%)
[  3] 23.0-24.0 sec    702 KBytes  5.75 Mbits/sec  2.349 ms  397/  886 (45%)
[  3] 24.0-25.0 sec    156 KBytes  1.28 Mbits/sec  35.780 ms    0/  109 (0%)
[  3] 25.0-26.0 sec    111 KBytes    906 Kbits/sec  25.621 ms    0/   77 (0%)
[  3] 26.0-27.0 sec    139 KBytes  1.14 Mbits/sec  21.186 ms    0/   97 (0%)
[  3] 27.0-28.0 sec    402 KBytes  3.29 Mbits/sec  3.818 ms    0/  280 (0%)
[  3] 28.0-29.0 sec    780 KBytes  6.39 Mbits/sec  3.695 ms    0/  543 (0%)
[  3] 29.0-30.0 sec  1.11 MBytes  9.34 Mbits/sec  3.210 ms    0/  794 (0%)
[  3] 30.0-31.0 sec  1.56 MBytes  13.1 Mbits/sec  1.502 ms    0/ 1116 (0%)
[  3] 31.0-32.0 sec  1.34 MBytes  11.2 Mbits/sec  1.817 ms    0/  955 (0%)
[  3] 32.0-33.0 sec    129 KBytes  1.06 Mbits/sec  1.385 ms    0/   90 (0%)
[  3] 33.0-34.0 sec  0.00 Bytes  0.00 bits/sec  1.385 ms    0/    0 (nan%)
[  3] 34.0-35.0 sec    593 KBytes  4.86 Mbits/sec  3.090 ms  430/  843 (51%)
[  3] 35.0-36.0 sec    210 KBytes  1.72 Mbits/sec  13.811 ms    0/  146 (0%)
[  3] 36.0-37.0 sec    109 KBytes    894 Kbits/sec  32.685 ms    0/   76 (0%)
[  3] 37.0-38.0 sec    129 KBytes  1.06 Mbits/sec  12.335 ms    0/   90 (0%)
[  3] 38.0-39.0 sec    370 KBytes  3.03 Mbits/sec  4.227 ms    0/  258 (0%)
[  3] 39.0-40.0 sec    778 KBytes  6.37 Mbits/sec  4.312 ms    0/  542 (0%)
[  3] 40.0-41.0 sec  1.09 MBytes  9.15 Mbits/sec  1.735 ms    0/  778 (0%)
[  3] 41.0-42.0 sec  1.53 MBytes  12.9 Mbits/sec  1.077 ms    0/ 1094 (0%)
[  3] 42.0-43.0 sec  1.50 MBytes  12.6 Mbits/sec  2.631 ms    0/ 1069 (0%)
[  3] 43.0-44.0 sec    185 KBytes  1.52 Mbits/sec  1.203 ms    0/  129 (0%)
[  3] 44.0-45.0 sec  0.00 Bytes  0.00 bits/sec  1.203 ms    0/    0 (nan%)
[  3] 45.0-46.0 sec    662 KBytes  5.42 Mbits/sec  2.283 ms  407/  868 (47%)
[  3] 46.0-47.0 sec    237 KBytes  1.94 Mbits/sec  13.562 ms    0/  165 (0%)
[  3] 47.0-48.0 sec    109 KBytes    894 Kbits/sec  35.074 ms    0/   76 (0%)
[  3] 48.0-49.0 sec    132 KBytes  1.08 Mbits/sec  11.849 ms    0/   92 (0%)
[  3] 49.0-50.0 sec    370 KBytes  3.03 Mbits/sec  4.068 ms    0/  258 (0%)
[  3] 50.0-51.0 sec    777 KBytes  6.36 Mbits/sec  4.439 ms    0/  541 (0%)
[  3] 51.0-52.0 sec  1.09 MBytes  9.15 Mbits/sec  1.842 ms    0/  778 (0%)
[  3] 52.0-53.0 sec  1.52 MBytes  12.7 Mbits/sec  1.803 ms    0/ 1081 (0%)
[  3] 53.0-54.0 sec  1.76 MBytes  14.7 Mbits/sec  1.593 ms    0/ 1252 (0%)
[  3] 54.0-55.0 sec    276 KBytes  2.26 Mbits/sec  1.054 ms    0/  192 (0%)
[  3] 55.0-56.0 sec  0.00 Bytes  0.00 bits/sec  1.054 ms    0/    0 (nan%)
[  3] 56.0-57.0 sec    534 KBytes  4.37 Mbits/sec  4.054 ms  430/  802 (54%)
[  3] 57.0-58.0 sec    263 KBytes  2.15 Mbits/sec  13.594 ms    0/  183 (0%)
[  3] 58.0-59.0 sec    106 KBytes    870 Kbits/sec  42.790 ms    0/   74 (0%)
[  3] 59.0-60.0 sec    121 KBytes    988 Kbits/sec  18.267 ms    0/   84 (0%)
[  3]  0.0-60.3 sec  33.7 MBytes  4.69 Mbits/sec  22.544 ms 2336/26385 (8.9%)
[  3]  0.0-60.3 sec  1 datagrams received out-of-order


5413 - old
----------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 56805
[  3]  0.0- 1.0 sec    108 KBytes    882 Kbits/sec  28.413 ms   11/   86 (13%)
[  3]  1.0- 2.0 sec    109 KBytes    894 Kbits/sec  22.192 ms    0/   76 (0%)
[  3]  2.0- 3.0 sec    108 KBytes    882 Kbits/sec  18.275 ms    0/   75 (0%)
[  3]  3.0- 4.0 sec    106 KBytes    870 Kbits/sec  39.404 ms    0/   74 (0%)
[  3]  4.0- 5.0 sec    108 KBytes    882 Kbits/sec  27.725 ms    0/   75 (0%)
[  3]  5.0- 6.0 sec    108 KBytes    882 Kbits/sec  21.480 ms    0/   75 (0%)
[  3]  6.0- 7.0 sec    106 KBytes    870 Kbits/sec  18.883 ms    0/   74 (0%)
[  3]  7.0- 8.0 sec    109 KBytes    894 Kbits/sec  34.303 ms    0/   76 (0%)
[  3]  8.0- 9.0 sec    109 KBytes    894 Kbits/sec  24.028 ms    0/   76 (0%)
[  3]  9.0-10.0 sec    106 KBytes    870 Kbits/sec  19.903 ms    0/   74 (0%)
[  3] 10.0-11.0 sec    109 KBytes    894 Kbits/sec  41.994 ms    0/   76 (0%)
[  3] 11.0-12.0 sec    109 KBytes    894 Kbits/sec  28.307 ms    0/   76 (0%)
[  3] 12.0-13.0 sec    106 KBytes    870 Kbits/sec  22.669 ms    0/   74 (0%)
[  3] 13.0-14.0 sec    108 KBytes    882 Kbits/sec  18.358 ms    0/   75 (0%)
[  3] 14.0-15.0 sec    109 KBytes    894 Kbits/sec  35.580 ms    0/   76 (0%)
[  3] 15.0-16.0 sec    108 KBytes    882 Kbits/sec  25.767 ms    0/   75 (0%)
[  3] 16.0-17.0 sec    106 KBytes    870 Kbits/sec  21.180 ms    0/   74 (0%)
[  3] 17.0-18.0 sec    106 KBytes    870 Kbits/sec  17.949 ms    0/   74 (0%)
[  3] 18.0-19.0 sec    106 KBytes    870 Kbits/sec  35.777 ms    0/   74 (0%)
[  3] 19.0-20.0 sec    108 KBytes    882 Kbits/sec  25.847 ms    0/   75 (0%)
[  3] 20.0-21.0 sec    108 KBytes    882 Kbits/sec  20.102 ms    0/   75 (0%)
[  3] 21.0-22.0 sec    109 KBytes    894 Kbits/sec  16.769 ms    0/   76 (0%)
[  3] 22.0-23.0 sec    109 KBytes    894 Kbits/sec  29.286 ms    0/   76 (0%)
[  3] 23.0-24.0 sec    109 KBytes    894 Kbits/sec  21.612 ms    0/   76 (0%)
[  3] 24.0-25.0 sec    108 KBytes    882 Kbits/sec  17.813 ms    0/   75 (0%)
[  3] 25.0-26.0 sec    109 KBytes    894 Kbits/sec  33.985 ms    0/   76 (0%)
[  3] 26.0-27.0 sec    106 KBytes    870 Kbits/sec  26.606 ms    0/   74 (0%)
[  3] 27.0-28.0 sec    106 KBytes    870 Kbits/sec  21.156 ms    0/   74 (0%)
[  3] 28.0-29.0 sec    108 KBytes    882 Kbits/sec  18.012 ms    0/   75 (0%)
[  3] 29.0-30.0 sec    108 KBytes    882 Kbits/sec  32.733 ms    0/   75 (0%)
[  3] 30.0-31.0 sec    109 KBytes    894 Kbits/sec  23.418 ms    0/   76 (0%)
[  3] 31.0-32.0 sec    108 KBytes    882 Kbits/sec  18.921 ms    0/   75 (0%)
[  3] 32.0-33.0 sec    108 KBytes    882 Kbits/sec  40.147 ms    0/   75 (0%)
[  3] 33.0-34.0 sec    109 KBytes    894 Kbits/sec  27.288 ms    0/   76 (0%)
[  3] 34.0-35.0 sec    109 KBytes    894 Kbits/sec  20.471 ms    0/   76 (0%)
[  3] 35.0-36.0 sec    108 KBytes    882 Kbits/sec  17.623 ms    0/   75 (0%)
[  3] 36.0-37.0 sec    109 KBytes    894 Kbits/sec  31.486 ms    0/   76 (0%)
[  3] 37.0-38.0 sec    109 KBytes    894 Kbits/sec  22.784 ms    0/   76 (0%)
[  3] 38.0-39.0 sec    109 KBytes    894 Kbits/sec  18.150 ms    0/   76 (0%)
[  3] 39.0-40.0 sec    109 KBytes    894 Kbits/sec  35.253 ms    0/   76 (0%)
[  3] 40.0-41.0 sec    103 KBytes    847 Kbits/sec  29.593 ms    0/   72 (0%)
[  3] 41.0-42.0 sec    108 KBytes    882 Kbits/sec  21.835 ms    0/   75 (0%)
[  3] 42.0-43.0 sec    108 KBytes    882 Kbits/sec  18.173 ms    0/   75 (0%)
[  3] 43.0-44.0 sec    109 KBytes    894 Kbits/sec  34.021 ms    0/   76 (0%)
[  3] 44.0-45.0 sec    109 KBytes    894 Kbits/sec  24.144 ms    0/   76 (0%)
[  3] 45.0-46.0 sec    108 KBytes    882 Kbits/sec  19.291 ms    0/   75 (0%)
[  3] 46.0-47.0 sec    108 KBytes    882 Kbits/sec  42.682 ms    0/   75 (0%)
[  3] 47.0-48.0 sec    105 KBytes    858 Kbits/sec  32.320 ms    0/   73 (0%)
[  3] 48.0-49.0 sec    109 KBytes    894 Kbits/sec  22.861 ms    0/   76 (0%)
[  3] 49.0-50.0 sec    109 KBytes    894 Kbits/sec  18.203 ms    0/   76 (0%)
[  3] 50.0-51.0 sec    109 KBytes    894 Kbits/sec  35.487 ms    0/   76 (0%)
[  3] 51.0-52.0 sec    106 KBytes    870 Kbits/sec  26.665 ms    0/   74 (0%)
[  3] 52.0-53.0 sec    108 KBytes    882 Kbits/sec  21.349 ms    0/   75 (0%)
[  3] 53.0-54.0 sec    109 KBytes    894 Kbits/sec  17.185 ms    0/   76 (0%)
[  3] 54.0-55.0 sec    108 KBytes    882 Kbits/sec  30.991 ms    0/   75 (0%)
[  3] 55.0-56.0 sec    109 KBytes    894 Kbits/sec  22.754 ms    0/   76 (0%)
[  3] 56.0-57.0 sec    109 KBytes    894 Kbits/sec  18.139 ms    0/   76 (0%)
[  3] 57.0-58.0 sec    106 KBytes    870 Kbits/sec  39.086 ms    0/   74 (0%)
[  3] 58.0-59.0 sec    109 KBytes    894 Kbits/sec  26.425 ms    0/   76 (0%)
[  3] 59.0-60.0 sec    109 KBytes    894 Kbits/sec  20.040 ms    0/   76 (0%)
[  3]  0.0-60.6 sec  6.39 MBytes    884 Kbits/sec  40.237 ms   10/ 4566 (0.22%)
[  3]  0.0-60.6 sec  1 datagrams received out-of-order

5413 - locked at 24M
--------------------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 52228
[  3]  0.0- 1.0 sec  1.86 MBytes  15.6 Mbits/sec  2.076 ms    0/ 1330 (0%)
[  3]  1.0- 2.0 sec  1.90 MBytes  15.9 Mbits/sec  1.897 ms    0/ 1354 (0%)
[  3]  2.0- 3.0 sec  1.79 MBytes  15.0 Mbits/sec  1.680 ms    0/ 1279 (0%)
[  3]  3.0- 4.0 sec  1.87 MBytes  15.7 Mbits/sec  2.079 ms    0/ 1337 (0%)
[  3]  4.0- 5.0 sec  1.89 MBytes  15.9 Mbits/sec  0.974 ms    0/ 1351 (0%)
[  3]  5.0- 6.0 sec  1.92 MBytes  16.1 Mbits/sec  1.950 ms    1/ 1369 (0.073%)
[  3]  6.0- 7.0 sec  1.89 MBytes  15.9 Mbits/sec  1.266 ms    0/ 1348 (0%)
[  3]  7.0- 8.0 sec  1.89 MBytes  15.9 Mbits/sec  1.312 ms    0/ 1349 (0%)
[  3]  8.0- 9.0 sec  1.85 MBytes  15.5 Mbits/sec  2.175 ms    0/ 1320 (0%)
[  3]  9.0-10.0 sec  1.89 MBytes  15.9 Mbits/sec  0.989 ms    0/ 1349 (0%)
[  3] 10.0-11.0 sec  1.90 MBytes  16.0 Mbits/sec  1.526 ms    0/ 1357 (0%)
[  3] 11.0-12.0 sec  1.91 MBytes  16.0 Mbits/sec  1.637 ms    0/ 1361 (0%)
[  3] 12.0-13.0 sec  1.89 MBytes  15.9 Mbits/sec  1.860 ms    0/ 1350 (0%)
[  3] 13.0-14.0 sec  1.91 MBytes  16.0 Mbits/sec  1.276 ms    0/ 1359 (0%)
[  3] 14.0-15.0 sec  1.86 MBytes  15.6 Mbits/sec  1.993 ms    0/ 1329 (0%)
[  3] 15.0-16.0 sec  1.79 MBytes  15.0 Mbits/sec  1.056 ms    0/ 1274 (0%)
[  3] 16.0-17.0 sec  1.75 MBytes  14.7 Mbits/sec  1.661 ms    0/ 1251 (0%)
[  3] 17.0-18.0 sec  1.63 MBytes  13.7 Mbits/sec  1.495 ms    0/ 1162 (0%)
[  3] 18.0-19.0 sec  1.70 MBytes  14.3 Mbits/sec  1.059 ms    1/ 1213 (0.082%)
[  3] 19.0-20.0 sec  1.71 MBytes  14.3 Mbits/sec  1.994 ms    0/ 1218 (0%)
[  3] 20.0-21.0 sec  1.68 MBytes  14.1 Mbits/sec  1.528 ms    0/ 1198 (0%)
[  3] 21.0-22.0 sec  1.62 MBytes  13.6 Mbits/sec  1.647 ms    0/ 1156 (0%)
[  3] 22.0-23.0 sec  1.66 MBytes  14.0 Mbits/sec  1.779 ms    0/ 1187 (0%)
[  3] 23.0-24.0 sec  1.70 MBytes  14.2 Mbits/sec  2.449 ms    0/ 1210 (0%)
[  3] 24.0-25.0 sec  1.74 MBytes  14.6 Mbits/sec  1.990 ms    0/ 1238 (0%)
[  3] 25.0-26.0 sec  1.85 MBytes  15.5 Mbits/sec  1.678 ms    0/ 1321 (0%)
[  3] 26.0-27.0 sec  1.87 MBytes  15.7 Mbits/sec  1.130 ms    0/ 1332 (0%)
[  3] 27.0-28.0 sec  1.93 MBytes  16.2 Mbits/sec  1.914 ms    0/ 1377 (0%)
[  3] 28.0-29.0 sec  1.89 MBytes  15.8 Mbits/sec  1.259 ms    0/ 1347 (0%)
[  3] 29.0-30.0 sec  1.90 MBytes  15.9 Mbits/sec  1.592 ms    0/ 1354 (0%)
[  3] 30.0-31.0 sec  1.86 MBytes  15.6 Mbits/sec  1.274 ms    0/ 1329 (0%)
[  3] 31.0-32.0 sec  1.88 MBytes  15.8 Mbits/sec  0.979 ms    0/ 1342 (0%)
[  3] 32.0-33.0 sec  1.88 MBytes  15.7 Mbits/sec  1.299 ms    0/ 1339 (0%)
[  3] 33.0-34.0 sec  1.87 MBytes  15.7 Mbits/sec  1.074 ms    0/ 1335 (0%)
[  3] 34.0-35.0 sec  1.86 MBytes  15.6 Mbits/sec  2.409 ms    0/ 1327 (0%)
[  3] 35.0-36.0 sec  1.91 MBytes  16.0 Mbits/sec  1.501 ms    0/ 1360 (0%)
[  3] 36.0-37.0 sec  1.88 MBytes  15.7 Mbits/sec  2.250 ms    0/ 1339 (0%)
[  3] 37.0-38.0 sec  1.88 MBytes  15.8 Mbits/sec  0.934 ms    0/ 1344 (0%)
[  3] 38.0-39.0 sec  1.89 MBytes  15.9 Mbits/sec  1.000 ms    0/ 1350 (0%)
[  3] 39.0-40.0 sec  1.84 MBytes  15.4 Mbits/sec  0.951 ms    0/ 1310 (0%)
[  3] 40.0-41.0 sec  1.88 MBytes  15.8 Mbits/sec  1.438 ms    0/ 1344 (0%)
[  3] 41.0-42.0 sec  1.87 MBytes  15.7 Mbits/sec  0.951 ms    0/ 1332 (0%)
[  3] 42.0-43.0 sec  1.88 MBytes  15.8 Mbits/sec  1.024 ms    0/ 1343 (0%)
[  3] 43.0-44.0 sec  1.89 MBytes  15.8 Mbits/sec  1.061 ms    0/ 1346 (0%)
[  3] 44.0-45.0 sec  1.88 MBytes  15.8 Mbits/sec  0.833 ms    0/ 1344 (0%)
[  3] 45.0-46.0 sec  1.88 MBytes  15.8 Mbits/sec  1.193 ms    0/ 1344 (0%)
[  3] 46.0-47.0 sec  1.91 MBytes  16.0 Mbits/sec  1.731 ms    0/ 1360 (0%)
[  3] 47.0-48.0 sec  1.83 MBytes  15.4 Mbits/sec  1.839 ms    0/ 1306 (0%)
[  3] 48.0-49.0 sec  1.80 MBytes  15.1 Mbits/sec  1.234 ms    0/ 1282 (0%)
[  3] 49.0-50.0 sec  1.31 MBytes  11.0 Mbits/sec  1.719 ms    0/  936 (0%)
[  3] 50.0-51.0 sec  1.60 MBytes  13.4 Mbits/sec  0.929 ms    0/ 1141 (0%)
[  3] 51.0-52.0 sec  1.72 MBytes  14.5 Mbits/sec  1.392 ms    0/ 1230 (0%)
[  3] 52.0-53.0 sec  1.86 MBytes  15.6 Mbits/sec  1.064 ms    0/ 1324 (0%)
[  3] 53.0-54.0 sec  1.95 MBytes  16.4 Mbits/sec  1.135 ms    0/ 1391 (0%)
[  3] 54.0-55.0 sec  1.92 MBytes  16.1 Mbits/sec  1.976 ms    0/ 1368 (0%)
[  3] 55.0-56.0 sec  1.79 MBytes  15.0 Mbits/sec  1.960 ms    0/ 1275 (0%)
[  3] 56.0-57.0 sec  1.89 MBytes  15.9 Mbits/sec  1.510 ms    0/ 1350 (0%)
[  3] 57.0-58.0 sec  1.89 MBytes  15.8 Mbits/sec  1.979 ms    0/ 1346 (0%)
[  3] 58.0-59.0 sec  1.90 MBytes  15.9 Mbits/sec  2.356 ms    0/ 1355 (0%)
[  3] 59.0-60.0 sec  1.90 MBytes  16.0 Mbits/sec  1.232 ms    0/ 1357 (0%)
[  3]  0.0-60.0 sec    110 MBytes  15.4 Mbits/sec  2.022 ms    2/78460 (0.0025%)


buggy 5213 - new
----------------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 54518
[  3]  0.0- 1.0 sec    106 KBytes    870 Kbits/sec  28.986 ms    0/   74 (0%)
[  3]  1.0- 2.0 sec    109 KBytes    894 Kbits/sec  22.215 ms    0/   76 (0%)
[  3]  2.0- 3.0 sec    108 KBytes    882 Kbits/sec  18.270 ms    0/   75 (0%)
[  3]  3.0- 4.0 sec    109 KBytes    894 Kbits/sec  35.364 ms    0/   76 (0%)
[  3]  4.0- 5.0 sec    109 KBytes    894 Kbits/sec  24.852 ms    0/   76 (0%)
[  3]  5.0- 6.0 sec    109 KBytes    894 Kbits/sec  19.227 ms    0/   76 (0%)
[  3]  6.0- 7.0 sec    108 KBytes    882 Kbits/sec  43.108 ms    0/   75 (0%)
[  3]  7.0- 8.0 sec    108 KBytes    882 Kbits/sec  29.529 ms    0/   75 (0%)
[  3]  8.0- 9.0 sec    108 KBytes    882 Kbits/sec  22.474 ms    0/   75 (0%)
[  3]  9.0-10.0 sec    108 KBytes    882 Kbits/sec  18.301 ms    0/   75 (0%)
[  3] 10.0-11.0 sec    108 KBytes    882 Kbits/sec  37.304 ms    0/   75 (0%)
[  3] 11.0-12.0 sec    108 KBytes    882 Kbits/sec  26.654 ms    0/   75 (0%)
[  3] 12.0-13.0 sec    108 KBytes    882 Kbits/sec  20.756 ms    0/   75 (0%)
[  3] 13.0-14.0 sec    108 KBytes    882 Kbits/sec  17.599 ms    0/   75 (0%)
[  3] 14.0-15.0 sec    109 KBytes    894 Kbits/sec  31.706 ms    0/   76 (0%)
[  3] 15.0-16.0 sec    108 KBytes    882 Kbits/sec  23.543 ms    0/   75 (0%)
[  3] 16.0-17.0 sec    109 KBytes    894 Kbits/sec  18.614 ms    0/   76 (0%)
[  3] 17.0-18.0 sec    108 KBytes    882 Kbits/sec  38.622 ms    0/   75 (0%)
[  3] 18.0-19.0 sec    108 KBytes    882 Kbits/sec  27.565 ms    0/   75 (0%)
[  3] 19.0-20.0 sec    109 KBytes    894 Kbits/sec  20.734 ms    0/   76 (0%)
[  3] 20.0-21.0 sec    108 KBytes    882 Kbits/sec  17.491 ms    0/   75 (0%)
[  3] 21.0-22.0 sec    109 KBytes    894 Kbits/sec  31.622 ms    0/   76 (0%)
[  3] 22.0-23.0 sec    105 KBytes    858 Kbits/sec  25.122 ms    0/   73 (0%)
[  3] 23.0-24.0 sec    106 KBytes    870 Kbits/sec  20.350 ms    0/   74 (0%)
[  3] 24.0-25.0 sec    108 KBytes    882 Kbits/sec  17.260 ms    0/   75 (0%)
[  3] 25.0-26.0 sec    108 KBytes    882 Kbits/sec  31.625 ms    0/   75 (0%)
[  3] 26.0-27.0 sec    109 KBytes    894 Kbits/sec  22.704 ms    0/   76 (0%)
[  3] 27.0-28.0 sec    109 KBytes    894 Kbits/sec  18.222 ms    0/   76 (0%)
[  3] 28.0-29.0 sec    108 KBytes    882 Kbits/sec  37.273 ms    0/   75 (0%)
[  3] 29.0-30.0 sec    108 KBytes    882 Kbits/sec  26.877 ms    0/   75 (0%)
[  3] 30.0-31.0 sec    109 KBytes    894 Kbits/sec  20.289 ms    0/   76 (0%)
[  3] 31.0-32.0 sec    108 KBytes    882 Kbits/sec  17.130 ms    0/   75 (0%)
[  3] 32.0-33.0 sec    109 KBytes    894 Kbits/sec  30.488 ms    0/   76 (0%)
[  3] 33.0-34.0 sec    109 KBytes    894 Kbits/sec  22.206 ms    0/   76 (0%)
[  3] 34.0-35.0 sec    108 KBytes    882 Kbits/sec  18.197 ms    0/   75 (0%)
[  3] 35.0-36.0 sec    109 KBytes    894 Kbits/sec  35.741 ms    0/   76 (0%)
[  3] 36.0-37.0 sec    108 KBytes    882 Kbits/sec  25.775 ms    0/   75 (0%)
[  3] 37.0-38.0 sec    109 KBytes    894 Kbits/sec  19.618 ms    0/   76 (0%)
[  3] 38.0-39.0 sec    108 KBytes    882 Kbits/sec  16.985 ms    0/   75 (0%)
[  3] 39.0-40.0 sec    109 KBytes    894 Kbits/sec  29.361 ms    0/   76 (0%)
[  3] 40.0-41.0 sec    108 KBytes    882 Kbits/sec  22.500 ms    0/   75 (0%)
[  3] 41.0-42.0 sec    108 KBytes    882 Kbits/sec  18.246 ms    0/   75 (0%)
[  3] 42.0-43.0 sec    108 KBytes    882 Kbits/sec  36.884 ms    0/   75 (0%)
[  3] 43.0-44.0 sec    109 KBytes    894 Kbits/sec  25.659 ms    0/   76 (0%)
[  3] 44.0-45.0 sec    109 KBytes    894 Kbits/sec  19.738 ms    0/   76 (0%)
[  3] 45.0-46.0 sec    109 KBytes    894 Kbits/sec  41.998 ms    0/   76 (0%)
[  3] 46.0-47.0 sec    109 KBytes    894 Kbits/sec  28.284 ms    0/   76 (0%)
[  3] 47.0-48.0 sec    109 KBytes    894 Kbits/sec  21.218 ms    0/   76 (0%)
[  3] 48.0-49.0 sec    109 KBytes    894 Kbits/sec  17.364 ms    0/   76 (0%)
[  3] 49.0-50.0 sec    109 KBytes    894 Kbits/sec  31.410 ms    0/   76 (0%)
[  3] 50.0-51.0 sec    108 KBytes    882 Kbits/sec  23.454 ms    0/   75 (0%)
[  3] 51.0-52.0 sec    109 KBytes    894 Kbits/sec  18.596 ms    0/   76 (0%)
[  3] 52.0-53.0 sec    109 KBytes    894 Kbits/sec  37.050 ms    0/   76 (0%)
[  3] 53.0-54.0 sec    108 KBytes    882 Kbits/sec  26.519 ms    0/   75 (0%)
[  3] 54.0-55.0 sec    108 KBytes    882 Kbits/sec  20.822 ms    0/   75 (0%)
[  3] 55.0-56.0 sec    109 KBytes    894 Kbits/sec  17.169 ms    0/   76 (0%)
[  3] 56.0-57.0 sec    108 KBytes    882 Kbits/sec  31.968 ms    0/   75 (0%)
[  3] 57.0-58.0 sec    108 KBytes    882 Kbits/sec  23.726 ms    0/   75 (0%)
[  3] 58.0-59.0 sec    106 KBytes    870 Kbits/sec  19.529 ms    0/   74 (0%)
[  3] 59.0-60.0 sec    106 KBytes    870 Kbits/sec  16.992 ms    0/   74 (0%)
[  3]  0.0-60.5 sec  6.39 MBytes    886 Kbits/sec  40.698 ms    0/ 4555 (0%)


buggy 5213 - old
----------------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 39925
[  3]  0.0- 1.0 sec    105 KBytes    858 Kbits/sec  28.859 ms    0/   73 (0%)
[  3]  1.0- 2.0 sec    109 KBytes    894 Kbits/sec  22.118 ms    0/   76 (0%)
[  3]  2.0- 3.0 sec    111 KBytes    906 Kbits/sec  17.487 ms    0/   77 (0%)
[  3]  3.0- 4.0 sec    109 KBytes    894 Kbits/sec  32.625 ms    0/   76 (0%)
[  3]  4.0- 5.0 sec    109 KBytes    894 Kbits/sec  23.307 ms    0/   76 (0%)
[  3]  5.0- 6.0 sec    109 KBytes    894 Kbits/sec  18.435 ms    0/   76 (0%)
[  3]  6.0- 7.0 sec    111 KBytes    906 Kbits/sec  35.235 ms    0/   77 (0%)
[  3]  7.0- 8.0 sec    109 KBytes    894 Kbits/sec  24.753 ms    0/   76 (0%)
[  3]  8.0- 9.0 sec    109 KBytes    894 Kbits/sec  19.179 ms    0/   76 (0%)
[  3]  9.0-10.0 sec    111 KBytes    906 Kbits/sec  38.414 ms    0/   77 (0%)
[  3] 10.0-11.0 sec    109 KBytes    894 Kbits/sec  26.320 ms    0/   76 (0%)
[  3] 11.0-12.0 sec    109 KBytes    894 Kbits/sec  20.114 ms    0/   76 (0%)
[  3] 12.0-13.0 sec    109 KBytes    894 Kbits/sec  16.729 ms    0/   76 (0%)
[  3] 13.0-14.0 sec    109 KBytes    894 Kbits/sec  29.206 ms    0/   76 (0%)
[  3] 14.0-15.0 sec    109 KBytes    894 Kbits/sec  22.261 ms    0/   76 (0%)
[  3] 15.0-16.0 sec    109 KBytes    894 Kbits/sec  17.665 ms    0/   76 (0%)
[  3] 16.0-17.0 sec    108 KBytes    882 Kbits/sec  34.128 ms    0/   75 (0%)
[  3] 17.0-18.0 sec    109 KBytes    894 Kbits/sec  24.078 ms    0/   76 (0%)
[  3] 18.0-19.0 sec    111 KBytes    906 Kbits/sec  18.414 ms    0/   77 (0%)
[  3] 19.0-20.0 sec    109 KBytes    894 Kbits/sec  36.801 ms    0/   76 (0%)
[  3] 20.0-21.0 sec    109 KBytes    894 Kbits/sec  25.608 ms    0/   76 (0%)
[  3] 21.0-22.0 sec    111 KBytes    906 Kbits/sec  19.220 ms    0/   77 (0%)
[  3] 22.0-23.0 sec    109 KBytes    894 Kbits/sec  38.542 ms    0/   76 (0%)
[  3] 23.0-24.0 sec    109 KBytes    894 Kbits/sec  27.278 ms    0/   76 (0%)
[  3] 24.0-25.0 sec    109 KBytes    894 Kbits/sec  20.543 ms    0/   76 (0%)
[  3] 25.0-26.0 sec    109 KBytes    894 Kbits/sec  17.029 ms    0/   76 (0%)
[  3] 26.0-27.0 sec    109 KBytes    894 Kbits/sec  30.219 ms    0/   76 (0%)
[  3] 27.0-28.0 sec    111 KBytes    906 Kbits/sec  21.563 ms    0/   77 (0%)
[  3] 28.0-29.0 sec    109 KBytes    894 Kbits/sec  17.574 ms    0/   76 (0%)
[  3] 29.0-30.0 sec    109 KBytes    894 Kbits/sec  32.626 ms    0/   76 (0%)
[  3] 30.0-31.0 sec    106 KBytes    870 Kbits/sec  25.459 ms    0/   74 (0%)
[  3] 31.0-32.0 sec    109 KBytes    894 Kbits/sec  19.353 ms    0/   76 (0%)
[  3] 32.0-33.0 sec    109 KBytes    894 Kbits/sec  40.229 ms    0/   76 (0%)
[  3] 33.0-34.0 sec    108 KBytes    882 Kbits/sec  28.182 ms    0/   75 (0%)
[  3] 34.0-35.0 sec    109 KBytes    894 Kbits/sec  21.184 ms    0/   76 (0%)
[  3] 35.0-36.0 sec    108 KBytes    882 Kbits/sec  17.722 ms    0/   75 (0%)
[  3] 36.0-37.0 sec    109 KBytes    894 Kbits/sec  32.773 ms    0/   76 (0%)
[  3] 37.0-38.0 sec    108 KBytes    882 Kbits/sec  24.356 ms    0/   75 (0%)
[  3] 38.0-39.0 sec    109 KBytes    894 Kbits/sec  18.992 ms    0/   76 (0%)
[  3] 39.0-40.0 sec    109 KBytes    894 Kbits/sec  38.837 ms    0/   76 (0%)
[  3] 40.0-41.0 sec    108 KBytes    882 Kbits/sec  27.703 ms    0/   75 (0%)
[  3] 41.0-42.0 sec    109 KBytes    894 Kbits/sec  20.723 ms    0/   76 (0%)
[  3] 42.0-43.0 sec    109 KBytes    894 Kbits/sec  17.044 ms    0/   76 (0%)
[  3] 43.0-44.0 sec    109 KBytes    894 Kbits/sec  30.279 ms    0/   76 (0%)
[  3] 44.0-45.0 sec    109 KBytes    894 Kbits/sec  22.083 ms    0/   76 (0%)
[  3] 45.0-46.0 sec    109 KBytes    894 Kbits/sec  17.835 ms    0/   76 (0%)
[  3] 46.0-47.0 sec    109 KBytes    894 Kbits/sec  34.045 ms    0/   76 (0%)
[  3] 47.0-48.0 sec    109 KBytes    894 Kbits/sec  24.038 ms    0/   76 (0%)
[  3] 48.0-49.0 sec    109 KBytes    894 Kbits/sec  18.827 ms    0/   76 (0%)
[  3] 49.0-50.0 sec    109 KBytes    894 Kbits/sec  38.538 ms    0/   76 (0%)
[  3] 50.0-51.0 sec    111 KBytes    906 Kbits/sec  25.513 ms    0/   77 (0%)
[  3] 51.0-52.0 sec    109 KBytes    894 Kbits/sec  19.665 ms    0/   76 (0%)
[  3] 52.0-53.0 sec    109 KBytes    894 Kbits/sec  41.888 ms    0/   76 (0%)
[  3] 53.0-54.0 sec    109 KBytes    894 Kbits/sec  28.206 ms    0/   76 (0%)
[  3] 54.0-55.0 sec    109 KBytes    894 Kbits/sec  21.016 ms    0/   76 (0%)
[  3] 55.0-56.0 sec    109 KBytes    894 Kbits/sec  17.303 ms    0/   76 (0%)
[  3] 56.0-57.0 sec    111 KBytes    906 Kbits/sec  30.269 ms    0/   77 (0%)
[  3] 57.0-58.0 sec    109 KBytes    894 Kbits/sec  22.099 ms    0/   76 (0%)
[  3] 58.0-59.0 sec    109 KBytes    894 Kbits/sec  17.931 ms    0/   76 (0%)
[  3] 59.0-60.0 sec    109 KBytes    894 Kbits/sec  33.954 ms    0/   76 (0%)
[  3]  0.0-60.8 sec  6.48 MBytes    893 Kbits/sec  40.233 ms    0/ 4619 (0%)
[  3]  0.0-60.8 sec  1 datagrams received out-of-order
read failed: Connection refused

buggy 5213 - locked at 18M
--------------------------

------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:   114 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.1 port 5001 connected with 192.168.254.253 port 47165
[  3]  0.0- 1.0 sec    973 KBytes  7.97 Mbits/sec  4.058 ms    0/  678 (0%)
[  3]  1.0- 2.0 sec  1.02 MBytes  8.55 Mbits/sec  2.260 ms    0/  727 (0%)
[  3]  2.0- 3.0 sec  1.02 MBytes  8.54 Mbits/sec  1.856 ms    0/  726 (0%)
[  3]  3.0- 4.0 sec  1.04 MBytes  8.75 Mbits/sec  1.752 ms    0/  744 (0%)
[  3]  4.0- 5.0 sec  1.01 MBytes  8.47 Mbits/sec  4.400 ms    0/  720 (0%)
[  3]  5.0- 6.0 sec  1.03 MBytes  8.61 Mbits/sec  1.713 ms    0/  732 (0%)
[  3]  6.0- 7.0 sec  1.30 MBytes  10.9 Mbits/sec  1.638 ms    0/  924 (0%)
[  3]  7.0- 8.0 sec  1.29 MBytes  10.8 Mbits/sec  1.343 ms    0/  922 (0%)
[  3]  8.0- 9.0 sec  1.30 MBytes  10.9 Mbits/sec  3.195 ms    0/  928 (0%)
[  3]  9.0-10.0 sec  1.32 MBytes  11.1 Mbits/sec  2.185 ms    0/  940 (0%)
[  3] 10.0-11.0 sec  1.32 MBytes  11.1 Mbits/sec  1.282 ms    0/  942 (0%)
[  3] 11.0-12.0 sec  1.31 MBytes  11.0 Mbits/sec  3.269 ms    0/  936 (0%)
[  3] 12.0-13.0 sec  1.31 MBytes  11.0 Mbits/sec  1.962 ms    0/  936 (0%)
[  3] 13.0-14.0 sec  1.31 MBytes  11.0 Mbits/sec  1.195 ms    0/  937 (0%)
[  3] 14.0-15.0 sec  1.32 MBytes  11.1 Mbits/sec  2.992 ms    0/  944 (0%)
[  3] 15.0-16.0 sec  1.30 MBytes  10.9 Mbits/sec  3.041 ms    0/  926 (0%)
[  3] 16.0-17.0 sec  1.31 MBytes  11.0 Mbits/sec  2.477 ms    0/  936 (0%)
[  3] 17.0-18.0 sec  1.32 MBytes  11.1 Mbits/sec  1.744 ms    0/  940 (0%)
[  3] 18.0-19.0 sec  1.31 MBytes  11.0 Mbits/sec  1.581 ms    0/  937 (0%)
[  3] 19.0-20.0 sec  1.34 MBytes  11.2 Mbits/sec  1.471 ms    0/  956 (0%)
[  3] 20.0-21.0 sec  1.31 MBytes  11.0 Mbits/sec  1.629 ms    0/  933 (0%)
[  3] 21.0-22.0 sec  1.37 MBytes  11.5 Mbits/sec  2.259 ms    0/  977 (0%)
[  3] 22.0-23.0 sec  1.40 MBytes  11.7 Mbits/sec  2.398 ms    0/  996 (0%)
[  3] 23.0-24.0 sec  1.39 MBytes  11.6 Mbits/sec  3.008 ms    0/  988 (0%)
[  3] 24.0-25.0 sec  1.41 MBytes  11.8 Mbits/sec  2.801 ms    0/ 1004 (0%)
[  3] 25.0-26.0 sec  1.39 MBytes  11.7 Mbits/sec  1.777 ms    0/  994 (0%)
[  3] 26.0-27.0 sec  1.38 MBytes  11.6 Mbits/sec  2.815 ms    0/  986 (0%)
[  3] 27.0-28.0 sec  1.38 MBytes  11.5 Mbits/sec  1.334 ms    0/  982 (0%)
[  3] 28.0-29.0 sec  1.37 MBytes  11.5 Mbits/sec  1.874 ms    0/  980 (0%)
[  3] 29.0-30.0 sec  1.39 MBytes  11.7 Mbits/sec  1.801 ms    0/  995 (0%)
[  3] 30.0-31.0 sec  1.38 MBytes  11.6 Mbits/sec  1.018 ms    0/  983 (0%)
[  3] 31.0-32.0 sec  1.36 MBytes  11.4 Mbits/sec  1.483 ms    0/  968 (0%)
[  3] 32.0-33.0 sec  1.38 MBytes  11.5 Mbits/sec  1.919 ms    0/  981 (0%)
[  3] 33.0-34.0 sec  1.38 MBytes  11.5 Mbits/sec  1.248 ms    0/  982 (0%)
[  3] 34.0-35.0 sec  1.39 MBytes  11.7 Mbits/sec  1.649 ms    0/  994 (0%)
[  3] 35.0-36.0 sec  1.36 MBytes  11.4 Mbits/sec  1.479 ms    0/  973 (0%)
[  3] 36.0-37.0 sec  1.31 MBytes  11.0 Mbits/sec  2.953 ms    0/  936 (0%)
[  3] 37.0-38.0 sec  1.31 MBytes  11.0 Mbits/sec  1.862 ms    0/  934 (0%)
[  3] 38.0-39.0 sec  1.33 MBytes  11.2 Mbits/sec  2.341 ms    0/  950 (0%)
[  3] 39.0-40.0 sec  1.30 MBytes  10.9 Mbits/sec  2.196 ms    0/  926 (0%)
[  3] 40.0-41.0 sec  1.14 MBytes  9.60 Mbits/sec  2.827 ms    0/  816 (0%)
[  3] 41.0-42.0 sec  1.17 MBytes  9.80 Mbits/sec  2.091 ms    0/  833 (0%)
[  3] 42.0-43.0 sec  1.12 MBytes  9.42 Mbits/sec  2.489 ms    0/  801 (0%)
[  3] 43.0-44.0 sec  1.08 MBytes  9.06 Mbits/sec  1.849 ms    0/  770 (0%)
[  3] 44.0-45.0 sec  1.14 MBytes  9.57 Mbits/sec  3.914 ms    0/  814 (0%)
[  3] 45.0-46.0 sec  1.16 MBytes  9.73 Mbits/sec  1.979 ms    0/  827 (0%)
[  3] 46.0-47.0 sec  1.32 MBytes  11.0 Mbits/sec  1.560 ms    0/  939 (0%)
[  3] 47.0-48.0 sec  1.29 MBytes  10.9 Mbits/sec  1.514 ms    0/  923 (0%)
[  3] 48.0-49.0 sec  1.30 MBytes  10.9 Mbits/sec  1.651 ms    0/  930 (0%)
[  3] 49.0-50.0 sec  1.31 MBytes  11.0 Mbits/sec  1.273 ms    0/  935 (0%)
[  3] 50.0-51.0 sec  1.32 MBytes  11.1 Mbits/sec  2.045 ms    0/  940 (0%)
[  3] 51.0-52.0 sec  1.31 MBytes  11.0 Mbits/sec  1.331 ms    0/  938 (0%)
[  3] 52.0-53.0 sec  1.30 MBytes  10.9 Mbits/sec  1.484 ms    0/  927 (0%)
[  3] 53.0-54.0 sec  1.37 MBytes  11.5 Mbits/sec  2.499 ms    0/  975 (0%)
[  3] 54.0-55.0 sec  1.41 MBytes  11.8 Mbits/sec  1.902 ms    0/ 1005 (0%)
[  3] 55.0-56.0 sec  1.42 MBytes  11.9 Mbits/sec  1.441 ms    0/ 1011 (0%)
[  3] 56.0-57.0 sec  1.42 MBytes  11.9 Mbits/sec  2.671 ms    0/ 1013 (0%)
[  3] 57.0-58.0 sec  1.41 MBytes  11.8 Mbits/sec  2.405 ms    0/ 1003 (0%)
[  3] 58.0-59.0 sec  1.42 MBytes  11.9 Mbits/sec  1.369 ms    0/ 1011 (0%)
[  3] 59.0-60.0 sec  1.42 MBytes  11.9 Mbits/sec  2.615 ms    0/ 1012 (0%)
[  3]  0.0-60.1 sec  77.6 MBytes  10.8 Mbits/sec  3.345 ms    0/55349 (0%)

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 22:42           ` Nick Kossifidis
@ 2007-12-03 23:36             ` Mattias Nissler
  2007-12-04  1:41             ` Stefano Brivio
  1 sibling, 0 replies; 34+ messages in thread
From: Mattias Nissler @ 2007-12-03 23:36 UTC (permalink / raw)
  To: Nick Kossifidis
  Cc: Stefano Brivio, linux-wireless, John W. Linville, Johannes Berg

Hi Nick,

thanks for your input.

On Tue, 2007-12-04 at 00:42 +0200, Nick Kossifidis wrote: 
> Here are some tests with ath5k + your patches...
> 
> I've tested a 5213 and a 5413 card, both have poor phy performance (we
> still work on phy initialization,  txpower etc) that means they
> receive ok but they can't transmit well (with other supported cards
> i've got much better performance up to 27Mbits/sec but i didn't have
> one in hand while testing, if you want i can repeat the test).

Hm, so the rate control will probably limit TX rate more than necessary
because of transmission failures caused by the driver.

> 
> I've run iperf on the previous rate control, the patched one and with
> locked tx rate.

Looking at your data, it's interesting to see that TX rate varies a lot.
I don't know your setup, but I doubt this is due to noise/interference
varying at your place. Question is whether it's the drivers fault or the
rate control failing. But still the PID rate control performs better
than the old simple algorithm.

I'll run a similar set of tests on my rt61 for comparison.

Mattias



^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 22:42           ` Nick Kossifidis
  2007-12-03 23:36             ` Mattias Nissler
@ 2007-12-04  1:41             ` Stefano Brivio
  2007-12-04  8:15               ` Mattias Nissler
                                 ` (2 more replies)
  1 sibling, 3 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-04  1:41 UTC (permalink / raw)
  To: Nick Kossifidis
  Cc: Mattias Nissler, linux-wireless, John W. Linville, Johannes Berg

I would say that these results show that the derivative coefficient is too
high, or that the sharpening factor I introduced doesn't work that good.
Anyway, just by a lowering a bit the failed frames target, results should be
far better than the plain -simple algorithm.

I hacked up a quick patch as to speed up testing for tuning.

You can use a bashscript such as the one below for an automated test. It
takes two parameters, the first one is a file (described below) with
tunings, and the second one is the file with the output results. The input
file is a list of tunings separated by a newline; each tuning value is
separated by an underscore (_). Tuning values are: rc_imul (control interval
multiplier), rc_idiv (control interval divider), rc_pf (failed frames
percentage target), rc_p (P coefficient), rc_i (I coefficient), rc_d (D
coefficient), rc_sm_s (smoothing shift), rc_sh_s (sharpening shift) and
rc_sh_d (sharpening duration). It'd be great if you could test it with this
input file:

1_1_25_15_10_15_3_0_0
1_1_25_15_10_5_3_0_1
1_1_25_15_10_5_3_1_1
1_2_25_15_10_15_3_0_0

[such as ./pid_tuning.sh file_above test_output, where file_above is the file
whose contents are listed above :) ]

Here comes the bashscript (please replace variable values at the beginning):

---

#!/bin/bash

# How to start the interface
IF_START_CMD="wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant.conf -B"
# How to stop the interface
IF_STOP_CMD="killall wpa_supplicant"
# How to get an IP address - leave blank if not needed
IFCONFIG_CMD="ifconfig wlan0 192.168.1.3"
# Create a default route - leave blank if not needed
ROUTE_CMD="route add default gw 192.168.1.1"
# Module which depends on mac80211
DEPMODS="b43"
# iperf command
IPERF_CMD="iperf -c 192.168.1.100"

echo PID tuning test started at `date` > $2
echo >> $2
for i in `cat $1`; do
	echo -e 'rc_imul\trc_idiv\trc_pf\trc_p\trc_i\trc_d\trc_sm_s\trc_sh_s\trc_sh_d' >> $2
	echo -e `echo -n $i | cut -d'_' -f1`'\t'`echo -n $i | cut -d'_' -f2`'\t' \
	 `echo -n $i | cut -d'_' -f3`'\t'`echo -n $i | cut -d'_' -f4`'\t' \
	 `echo -n $i | cut -d'_' -f5`'\t'`echo -n $i | cut -d'_' -f6`'\t' \
	 `echo -n $i | cut -d'_' -f7`'\t'`echo -n $i | cut -d'_' -f8`'\t' \
	 `echo -n $i | cut -d'_' -f9`'\t' >> $2
	$IF_STOP_CMD
	for j in $DEPMODS; do
		/sbin/modprobe -r $j; done
	/sbin/modprobe -r mac80211
	/sbin/modprobe mac80211 rc_imul=`echo $i | cut -d'_' -f1` \
		rc_idiv=`echo $i | cut -d'_' -f2`
		rc_pf=`echo $i | cut -d'_' -f3` \
		rc_p=`echo $i | cut -d'_' -f4` \
		rc_i=`echo $i | cut -d'_' -f5` \
		rc_d=`echo $i | cut -d'_' -f6` \
		rc_sm_s=`echo $i | cut -d'_' -f7` \
		rc_sh_s=`echo $i | cut -d'_' -f8` \
		rc_sh_d=`echo $i | cut -d'_' -f9`
	for j in $DEPMODS; do
		/sbin/modprobe $j; done
	echo $IF_START_CMD
	$IF_START_CMD
	$IFCONFIG_CMD
	$ROUTE_CMD
	$IPERF_CMD >> $2
	echo >> $2
	echo ---- >> $2
	echo >> $2
done

---

And here comes the patch (applies on top of the original patch by Mattias and
the one I sent yesterday - ask me for a complete patch if needed):

---

Index: wireless-2.6/net/mac80211/rc80211_simple.c
===================================================================
--- wireless-2.6.orig/net/mac80211/rc80211_simple.c
+++ wireless-2.6/net/mac80211/rc80211_simple.c
@@ -19,6 +19,41 @@
 #include "ieee80211_rate.h"
 #include "debugfs.h"
 
+static int modparam_rc_imul = 1;
+module_param_named(rc_imul, modparam_rc_imul, int, 0444);
+MODULE_PARM_DESC(rc_imul, "PID rate control interval multiplier");
+
+static int modparam_rc_idiv = 1;
+module_param_named(rc_idiv, modparam_rc_idiv, int, 0444);
+MODULE_PARM_DESC(rc_idiv, "PID rate control interval divider");
+
+static int modparam_rc_pf = 20;
+module_param_named(rc_pf, modparam_rc_pf, int, 0444);
+MODULE_PARM_DESC(rc_pf, "PID rate control failed frames percentage target");
+
+static int modparam_rc_p = 15;
+module_param_named(rc_p, modparam_rc_p, int, 0444);
+MODULE_PARM_DESC(rc_p, "PID rate control proportional coefficient");
+
+static int modparam_rc_i = 10;
+module_param_named(rc_i, modparam_rc_i, int, 0444);
+MODULE_PARM_DESC(rc_i, "PID rate control integral coefficient");
+
+static int modparam_rc_d = 15;
+module_param_named(rc_d, modparam_rc_d, int, 0444);
+MODULE_PARM_DESC(rc_d, "PID rate control derivative coefficient");
+
+static int modparam_rc_sm_s = 3;
+module_param_named(rc_sm_s, modparam_rc_sm_s, int, 0444);
+MODULE_PARM_DESC(rc_sm_s, "PID rate control smoothing factor shift");
+
+static int modparam_rc_sh_s = 2;
+module_param_named(rc_sh_s, modparam_rc_sh_s, int, 0444);
+MODULE_PARM_DESC(rc_sh_s, "PID rate control sharpening factor shift");
+
+static int modparam_rc_sh_d = 3;
+module_param_named(rc_sh_d, modparam_rc_sh_d, int, 0444);
+MODULE_PARM_DESC(rc_sh_d, "PID rate control sharpening factor duration");
 
 /* This is an implementation of TX rate control algorithm that uses a PID
  * controller. Given a target failed frames rate, the controller decides about
@@ -251,7 +286,8 @@ static void rate_control_simple_tx_statu
 	/*
 	 * Update PID controller state.
 	 */
-	if (time_after(jiffies, srctrl->last_sample + RATE_CONTROL_INTERVAL)) {
+	if (time_after(jiffies, srctrl->last_sample +
+	    (HZ * modparam_rc_imul) / modparam_rc_idiv)) {
 		u32 pf;
 		s32 err_avg;
 		s32 err_prop;
@@ -267,7 +303,7 @@ static void rate_control_simple_tx_statu
 		 */
 		if (srctrl->tx_num_xmit == 0) {
 			pf = srctrl->last_pf;
-			srctrl->sharp_cnt = RATE_CONTROL_SHARPENING_DURATION;
+			srctrl->sharp_cnt = modparam_rc_sh_d;
 		} else {
 			pf = srctrl->tx_num_failed * 100 / srctrl->tx_num_xmit;
 			pf <<= RATE_CONTROL_ARITH_SHIFT;
@@ -277,22 +313,22 @@ static void rate_control_simple_tx_statu
 		}
 
 		/* Compute the proportional, integral and derivative errors. */
-		err_prop = RATE_CONTROL_TARGET_PF - pf;
+		err_prop = (modparam_rc_pf << RATE_CONTROL_ARITH_SHIFT) - pf;
 
-		err_avg = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
+		err_avg = srctrl->err_avg_sc >> modparam_rc_sh_s;
 		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
-		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
+		err_int = srctrl->err_avg_sc >> modparam_rc_sh_s;
 
 		err_der = (pf - srctrl->last_pf) *
-			  (1 + RATE_CONTROL_SHARPENING * srctrl->sharp_cnt);
+			  (1 + (1 << modparam_rc_sh_s) * srctrl->sharp_cnt);
 		srctrl->last_pf = pf;
 		if (srctrl->sharp_cnt)
 			srctrl->sharp_cnt--;
 
 		/* Compute the controller output. */
-		adj = (err_prop * RATE_CONTROL_COEFF_P
-		      + err_int * RATE_CONTROL_COEFF_I
-		      + err_der * RATE_CONTROL_COEFF_D)
+		adj = (err_prop * modparam_rc_p
+		      + err_int * modparam_rc_i
+		      + err_der * modparam_rc_d)
 			>> (2 * RATE_CONTROL_ARITH_SHIFT);
 
 		printk(KERN_DEBUG "rate_control: sample %d "


---

I'm privately sending you both as attachments for your convenience. Thank
you for testing.


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04  1:41             ` Stefano Brivio
@ 2007-12-04  8:15               ` Mattias Nissler
  2007-12-04 10:01                 ` Stefano Brivio
  2007-12-04 22:05               ` Nick Kossifidis
  2007-12-08  9:45               ` [RFC][PATCH] mac80211: Use PID controller for TX rate control Stefano Brivio
  2 siblings, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-04  8:15 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg

Hi Stefano,

On Tue, 2007-12-04 at 02:41 +0100, Stefano Brivio wrote:
> I would say that these results show that the derivative coefficient is too
> high, or that the sharpening factor I introduced doesn't work that good.
> Anyway, just by a lowering a bit the failed frames target, results should be
> far better than the plain -simple algorithm.

Um, if Nick says the device has problems transmitting frames, IMHO this
will make it quite impossible to get the PID rate control right by
tuning parameters. Of course you can set the failed frames percentage
target to 100, but that's certainly not what we want. While I'm at it,
we should really run tests with different target values to see what
target gives us the best throughput in noisy situations.

Just an idea for your hack: wouldn't it be easier if we had all these
parameters accessible via debugfs instead of module parameters? Also, it
might be useful to have the parameters in sysfs so they can be changed
also for production systems, once mac80211 is stable.

Having the parameters in debugfs would also make things much easier for
me, since mac80211 oopses on module unload every now and then. I think
that started with the 2.6.24 series. So far I haven't had the time to
figure out why.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04  8:15               ` Mattias Nissler
@ 2007-12-04 10:01                 ` Stefano Brivio
  2007-12-04 17:40                   ` Mattias Nissler
  0 siblings, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-04 10:01 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg

On Tue, 04 Dec 2007 09:15:03 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> Um, if Nick says the device has problems transmitting frames, IMHO this
> will make it quite impossible to get the PID rate control right by
> tuning parameters. Of course you can set the failed frames percentage
> target to 100, but that's certainly not what we want.

Ok, sure. But to some degree, having problems in transmitting frames
because of driver issues is an approximation of a noisy environment.
However, we can't do so much in this specific case.

> Just an idea for your hack: wouldn't it be easier if we had all these
> parameters accessible via debugfs instead of module parameters? Also, it
> might be useful to have the parameters in sysfs so they can be changed
> also for production systems, once mac80211 is stable.

They are in sysfs. You just need to set perm to 0644. But this is racy, and
you should implement some locking, and I just didn't want to bother about
this. It's not racy, if you make sure that the interface is down while you
write parameters. Of course, if we want these parameters to get into
mac80211, proper locking should be implemented.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-03 11:31       ` Mattias Nissler
@ 2007-12-04 13:40         ` Johannes Berg
  2007-12-04 17:45           ` Mattias Nissler
  2007-12-04 17:48           ` Stefano Brivio
  0 siblings, 2 replies; 34+ messages in thread
From: Johannes Berg @ 2007-12-04 13:40 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Tomas Winkler, Stefano Brivio, linux-wireless, John W. Linville

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]


> I already thought so. But the original "simple" algorithm is totally
> broken in most cases. Well, maybe except the cases perfect situation ->
> no tx failures -> full rate and bad situation -> lots of tx failures ->
> lowest rate. IMHO, we should just get rid of the old simple algorithm.

I tend to agree, but I guess we should rename it then and change the
default. Ultimately, we'll need to come up with some nl80211 API for
rate control algorithms that allows each algorithm to have different
parameters, similar to what tc(1) does for qdiscs.

If anybody's interested, here's what I'd do:

 (a) add new attributes "rate control algorithm" and "rate control
     algorithm attributes"
 (b) allow setting them with NL80211_CMD_SET_INTERFACE
 (c) the "rate control algorithm attributes" attribute is nested and
     contains per-algorithm information, the indexes in it are specific
     to each algorithm

This allows changing the algorithm as well as algorithm parameters.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 10:01                 ` Stefano Brivio
@ 2007-12-04 17:40                   ` Mattias Nissler
  2007-12-04 17:57                     ` Stefano Brivio
  2007-12-04 20:50                     ` Holger Schurig
  0 siblings, 2 replies; 34+ messages in thread
From: Mattias Nissler @ 2007-12-04 17:40 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg


On Tue, 2007-12-04 at 11:01 +0100, Stefano Brivio wrote:
> On Tue, 04 Dec 2007 09:15:03 +0100
> Mattias Nissler <mattias.nissler@gmx.de> wrote:
> 
> > Um, if Nick says the device has problems transmitting frames, IMHO this
> > will make it quite impossible to get the PID rate control right by
> > tuning parameters. Of course you can set the failed frames percentage
> > target to 100, but that's certainly not what we want.
> 
> Ok, sure. But to some degree, having problems in transmitting frames
> because of driver issues is an approximation of a noisy environment.
> However, we can't do so much in this specific case.

I don't think this data is useful for tuning the TX control algorithm at
all. In the case of a noisy channel, you can improve the rate of
successful transmission by switching to a more-robust rate. However, if
the driver just gets the parameters wrong, a slower rate won't help at
all, thus the feedback loop model on which the PID controller relies is
severely flawed.

> 
> > Just an idea for your hack: wouldn't it be easier if we had all these
> > parameters accessible via debugfs instead of module parameters? Also, it
> > might be useful to have the parameters in sysfs so they can be changed
> > also for production systems, once mac80211 is stable.
> 
> They are in sysfs. You just need to set perm to 0644. But this is racy, and
> you should implement some locking, and I just didn't want to bother about
> this. It's not racy, if you make sure that the interface is down while you
> write parameters. Of course, if we want these parameters to get into
> mac80211, proper locking should be implemented.

Ah, ok, module parameters show up in sysfs. This is good for testing,
but if we want to make some parameters available for everybody, we
cannot rely on module parameters, i.e. when mac80211 is compiled int the
kernel. I'd say we even want to be able to tweak the parameters on a per
device basis, we should really add them to mac80211 sysfs.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 13:40         ` Johannes Berg
@ 2007-12-04 17:45           ` Mattias Nissler
  2007-12-05 10:16             ` Johannes Berg
  2007-12-04 17:48           ` Stefano Brivio
  1 sibling, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-04 17:45 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Tomas Winkler, Stefano Brivio, linux-wireless, John W. Linville


On Tue, 2007-12-04 at 14:40 +0100, Johannes Berg wrote:
> > I already thought so. But the original "simple" algorithm is totally
> > broken in most cases. Well, maybe except the cases perfect situation ->
> > no tx failures -> full rate and bad situation -> lots of tx failures ->
> > lowest rate. IMHO, we should just get rid of the old simple algorithm.
> 
> I tend to agree, but I guess we should rename it then and change the
> default. Ultimately, we'll need to come up with some nl80211 API for
> rate control algorithms that allows each algorithm to have different
> parameters, similar to what tc(1) does for qdiscs.
> 
> If anybody's interested, here's what I'd do:
> 
>  (a) add new attributes "rate control algorithm" and "rate control
>      algorithm attributes"
>  (b) allow setting them with NL80211_CMD_SET_INTERFACE
>  (c) the "rate control algorithm attributes" attribute is nested and
>      contains per-algorithm information, the indexes in it are specific
>      to each algorithm
> 
> This allows changing the algorithm as well as algorithm parameters.

Ok, sounds good. What is the overall strategy for deciding what goes
into nl80211, what into sysfs?

I'll go ahead and implement the nl80211 way.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 13:40         ` Johannes Berg
  2007-12-04 17:45           ` Mattias Nissler
@ 2007-12-04 17:48           ` Stefano Brivio
  1 sibling, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-04 17:48 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Mattias Nissler, Tomas Winkler, linux-wireless, John W. Linville

On Tue, 04 Dec 2007 14:40:23 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:

> If anybody's interested, here's what I'd do:
> 
>  (a) add new attributes "rate control algorithm" and "rate control
>      algorithm attributes"
>  (b) allow setting them with NL80211_CMD_SET_INTERFACE
>  (c) the "rate control algorithm attributes" attribute is nested and
>      contains per-algorithm information, the indexes in it are specific
>      to each algorithm
> 
> This allows changing the algorithm as well as algorithm parameters.

This sounds great to me. Anyway, I'm still not completely convinced that we
need to actually make any parameter available for 'rc80211-pid', but it's
likely anyway. And that would be needed very likely for other rate control
algorithm, so yes, I agree with this.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 17:40                   ` Mattias Nissler
@ 2007-12-04 17:57                     ` Stefano Brivio
  2007-12-04 18:33                       ` Mattias Nissler
  2007-12-04 20:50                     ` Holger Schurig
  1 sibling, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-04 17:57 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg

On Tue, 04 Dec 2007 18:40:47 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> I don't think this data is useful for tuning the TX control algorithm at
> all. In the case of a noisy channel, you can improve the rate of
> successful transmission by switching to a more-robust rate. However, if
> the driver just gets the parameters wrong, a slower rate won't help at
> all, thus the feedback loop model on which the PID controller relies is
> severely flawed.

Well, I may object that here it looks like that setting a lower rate
actually yields a lower failed frames ratio. But I agree with you, this
data is suboptimal - at the very least - for helping us with tuning.

> Ah, ok, module parameters show up in sysfs. This is good for testing,
> but if we want to make some parameters available for everybody, we
> cannot rely on module parameters, i.e. when mac80211 is compiled int the
> kernel. I'd say we even want to be able to tweak the parameters on a per
> device basis, we should really add them to mac80211 sysfs.

Please see Johannes's proposal [1]. I tend to agree with that. Here comes
my plan: for testing, I'd say we can stick to those modparams I introduced
last night, setting perms to 644 and just being careful to bring down the
interface before changing them through sysfs. When we're done with testing,
we can decide which parameters need to be exported and which don't, and
then implement proper locking and exporting parameters through nl80211. Is
this OK for you?


[1] Message-Id: <1196775624.6060.52.camel@johannes.berg>, on linux-wireless.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 17:57                     ` Stefano Brivio
@ 2007-12-04 18:33                       ` Mattias Nissler
  2007-12-04 18:40                         ` Stefano Brivio
  0 siblings, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-04 18:33 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg


> Please see Johannes's proposal [1]. I tend to agree with that. Here comes
> my plan: for testing, I'd say we can stick to those modparams I introduced
> last night, setting perms to 644 and just being careful to bring down the
> interface before changing them through sysfs. When we're done with testing,
> we can decide which parameters need to be exported and which don't, and
> then implement proper locking and exporting parameters through nl80211. Is
> this OK for you?

This is fine with me, let's go ahead with this approach. I'll do some
test runs tonight to further tune the parameters. I also intend to clean
up the code a little.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 18:33                       ` Mattias Nissler
@ 2007-12-04 18:40                         ` Stefano Brivio
  0 siblings, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-04 18:40 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Nick Kossifidis, linux-wireless, John W. Linville, Johannes Berg

On Tue, 04 Dec 2007 19:33:06 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> This is fine with me, let's go ahead with this approach. I'll do some
> test runs tonight to further tune the parameters. I also intend to clean
> up the code a little.

Yes, good idea. I avoided to do this because I didn't want to post new
patches which included yours - didn't want to appear to be stealing or
anything.


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 17:40                   ` Mattias Nissler
  2007-12-04 17:57                     ` Stefano Brivio
@ 2007-12-04 20:50                     ` Holger Schurig
  2007-12-04 20:57                       ` Mattias Nissler
  1 sibling, 1 reply; 34+ messages in thread
From: Holger Schurig @ 2007-12-04 20:50 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Stefano Brivio, Nick Kossifidis, linux-wireless,
	John W. Linville, Johannes Berg

> but if we want to make some parameters available for everybody, we
> cannot rely on module parameters, i.e. when mac80211 is compiled int
> the kernel.

It doesn't matter if a something is compiled as a module or if this 
something is part of a monolithic kernel. The "something" will still 
get it's /sys/module/SOMETHING/ directory and if it happens to have 
parameters, a /sys/module/SOMETHING/parameters/ directory.

# lsmod
Module                  Size  Used by
ide_scsi               11848  0
usb_storage            54400  0
cx24110                 6084  1
dvb_bt8xx              13892  0
dvb_core               72444  1 dvb_bt8xx
bt878                   8488  1 dvb_bt8xx
bttv                  163508  2 dvb_bt8xx,bt878
ir_common              30148  1 bttv
compat_ioctl32           960  1 bttv
i2c_algo_bit            5380  1 bttv
videobuf_dma_sg        10884  1 bttv
videobuf_core          13956  2 bttv,videobuf_dma_sg
btcx_risc               3848  1 bttv
tveeprom               13968  1 bttv
videodev               25792  1 bttv
v4l2_common            15168  2 bttv,videodev
v4l1_compat            13508  2 bttv,videodev
# ls /sys/module/
8250/       compat_ioctl32/  i8042/      mtrr/      snd/           
v4l2_common/
acpi/       cx24110/         ide_cd/     printk/    snd_intel8x0/  
videobuf_core/
atkbd/      drm/             ide_scsi/   psmouse/   snd_pcm_oss/   
videobuf_dma_sg/
bt878/      dvb_bt8xx/       ir_common/  rcupdate/  tcp_cubic/     
videodev/
btcx_risc/  dvb_core/        keyboard/   scsi_mod/  tveeprom/      vt/
bttv/       ehci_hcd/        libusual/   sg/        usb_storage/
cdrom/      hid/             loop/       sis5595/   usbcore/
cn/         i2c_algo_bit/    mousedev/   sis900/    v4l1_compat/

But don't do it for rate control. Maybe you want to have on wlan0 a 
different rate control than on wlan1. And 
a /sys/module/SOMETHING/parameters/ exported variables are 
module-global.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 20:50                     ` Holger Schurig
@ 2007-12-04 20:57                       ` Mattias Nissler
  0 siblings, 0 replies; 34+ messages in thread
From: Mattias Nissler @ 2007-12-04 20:57 UTC (permalink / raw)
  To: Holger Schurig
  Cc: Stefano Brivio, Nick Kossifidis, linux-wireless,
	John W. Linville, Johannes Berg


On Tue, 2007-12-04 at 21:50 +0100, Holger Schurig wrote:
> > but if we want to make some parameters available for everybody, we
> > cannot rely on module parameters, i.e. when mac80211 is compiled int
> > the kernel.
> 
> It doesn't matter if a something is compiled as a module or if this 
> something is part of a monolithic kernel. The "something" will still 
> get it's /sys/module/SOMETHING/ directory and if it happens to have 
> parameters, a /sys/module/SOMETHING/parameters/ directory.

Thanks, good to know.

> But don't do it for rate control. Maybe you want to have on wlan0 a 
> different rate control than on wlan1. And 
> a /sys/module/SOMETHING/parameters/ exported variables are 
> module-global.

Agreed.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04  1:41             ` Stefano Brivio
  2007-12-04  8:15               ` Mattias Nissler
@ 2007-12-04 22:05               ` Nick Kossifidis
  2007-12-05  7:49                 ` Holger Schurig
  2007-12-08  9:45               ` [RFC][PATCH] mac80211: Use PID controller for TX rate control Stefano Brivio
  2 siblings, 1 reply; 34+ messages in thread
From: Nick Kossifidis @ 2007-12-04 22:05 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Mattias Nissler, linux-wireless, John W. Linville, Johannes Berg

There you go ;-)

5213
------

PID tuning test started at Tue Dec 4 23:51:34 EET 2007

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	15	 3	0	 0	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.8 port 39656 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    300 KBytes  2.46 Mbits/sec
[  3]  1.0- 2.0 sec    379 KBytes  3.10 Mbits/sec
[  3]  2.0- 3.0 sec    774 KBytes  6.34 Mbits/sec
[  3]  3.0- 4.0 sec  1.05 MBytes  8.80 Mbits/sec
[  3]  4.0- 5.0 sec  1.30 MBytes  10.9 Mbits/sec
[  3]  5.0- 6.0 sec  1.08 MBytes  9.03 Mbits/sec
[  3]  6.0- 7.0 sec    237 KBytes  1.94 Mbits/sec
[  3]  7.0- 8.0 sec    189 KBytes  1.55 Mbits/sec
[  3]  8.0- 9.0 sec    616 KBytes  5.05 Mbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 11.0-12.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 12.0-13.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 13.0-14.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 14.0-15.0 sec    910 KBytes  7.46 Mbits/sec
[  3] 15.0-16.0 sec  1.03 MBytes  8.63 Mbits/sec
[  3] 16.0-17.0 sec  1012 KBytes  8.29 Mbits/sec
[  3] 17.0-18.0 sec    144 KBytes  1.18 Mbits/sec
[  3] 18.0-19.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 19.0-20.0 sec    521 KBytes  4.27 Mbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 22.0-23.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 23.0-24.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 24.0-25.0 sec    670 KBytes  5.49 Mbits/sec
[  3] 25.0-26.0 sec    887 KBytes  7.27 Mbits/sec
[  3] 26.0-27.0 sec  1.12 MBytes  9.42 Mbits/sec
[  3] 27.0-28.0 sec  1001 KBytes  8.20 Mbits/sec
[  3] 28.0-29.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 29.0-30.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 30.0-31.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 31.0-32.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 32.0-33.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 33.0-34.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 34.0-35.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 35.0-36.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 36.0-37.0 sec  1.05 MBytes  8.78 Mbits/sec
[  3] 37.0-38.0 sec  1.27 MBytes  10.7 Mbits/sec
[  3] 38.0-39.0 sec  1.31 MBytes  11.0 Mbits/sec
[  3] 39.0-40.0 sec    197 KBytes  1.61 Mbits/sec
[  3] 40.0-41.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 41.0-42.0 sec    474 KBytes  3.88 Mbits/sec
[  3] 42.0-43.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 43.0-44.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 44.0-45.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 45.0-46.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 46.0-47.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 47.0-48.0 sec    933 KBytes  7.64 Mbits/sec
[  3] 48.0-49.0 sec  1.21 MBytes  10.2 Mbits/sec
[  3] 49.0-50.0 sec  1.15 MBytes  9.64 Mbits/sec
[  3] 50.0-51.0 sec    207 KBytes  1.69 Mbits/sec
[  3] 51.0-52.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 52.0-53.0 sec    521 KBytes  4.27 Mbits/sec
[  3] 53.0-54.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 54.0-55.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 55.0-56.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 56.0-57.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 57.0-58.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 58.0-59.0 sec    962 KBytes  7.88 Mbits/sec
[  3] 59.0-60.0 sec  1.19 MBytes  9.98 Mbits/sec
[  3]  0.0-60.0 sec  31.4 MBytes  4.39 Mbits/sec
[  3] Sent 22396 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  3.242 ms 1413/22395 (6.3%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	5	 3	0	 1	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.8 port 43701 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    297 KBytes  2.43 Mbits/sec
[  3]  1.0- 2.0 sec    426 KBytes  3.49 Mbits/sec
[  3]  2.0- 3.0 sec    827 KBytes  6.77 Mbits/sec
[  3]  3.0- 4.0 sec  1.07 MBytes  9.01 Mbits/sec
[  3]  4.0- 5.0 sec  1.42 MBytes  11.9 Mbits/sec
[  3]  5.0- 6.0 sec  1.31 MBytes  11.0 Mbits/sec
[  3]  6.0- 7.0 sec    237 KBytes  1.94 Mbits/sec
[  3]  7.0- 8.0 sec    237 KBytes  1.94 Mbits/sec
[  3]  8.0- 9.0 sec    680 KBytes  5.57 Mbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 11.0-12.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 12.0-13.0 sec    426 KBytes  3.49 Mbits/sec
[  3] 13.0-14.0 sec    712 KBytes  5.83 Mbits/sec
[  3] 14.0-15.0 sec  1.01 MBytes  8.48 Mbits/sec
[  3] 15.0-16.0 sec  1.27 MBytes  10.6 Mbits/sec
[  3] 16.0-17.0 sec  1.27 MBytes  10.6 Mbits/sec
[  3] 17.0-18.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 18.0-19.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 19.0-20.0 sec    616 KBytes  5.05 Mbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 22.0-23.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 23.0-24.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 24.0-25.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 25.0-26.0 sec  1002 KBytes  8.21 Mbits/sec
[  3] 26.0-27.0 sec  1.35 MBytes  11.3 Mbits/sec
[  3] 27.0-28.0 sec  1.27 MBytes  10.7 Mbits/sec
[  3] 28.0-29.0 sec    191 KBytes  1.56 Mbits/sec
[  3] 29.0-30.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 30.0-31.0 sec    426 KBytes  3.49 Mbits/sec
[  3] 31.0-32.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 32.0-33.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 33.0-34.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 34.0-35.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 35.0-36.0 sec    616 KBytes  5.05 Mbits/sec
[  3] 36.0-37.0 sec    805 KBytes  6.60 Mbits/sec
[  3] 37.0-38.0 sec    883 KBytes  7.23 Mbits/sec
[  3] 38.0-39.0 sec    843 KBytes  6.90 Mbits/sec
[  3] 39.0-40.0 sec    144 KBytes  1.18 Mbits/sec
[  3] 40.0-41.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 41.0-42.0 sec    426 KBytes  3.49 Mbits/sec
[  3] 42.0-43.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 43.0-44.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 44.0-45.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 45.0-46.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 46.0-47.0 sec    568 KBytes  4.66 Mbits/sec
[  3] 47.0-48.0 sec    774 KBytes  6.34 Mbits/sec
[  3] 48.0-49.0 sec  1018 KBytes  8.34 Mbits/sec
[  3] 49.0-50.0 sec  1.24 MBytes  10.4 Mbits/sec
[  3] 50.0-51.0 sec    290 KBytes  2.38 Mbits/sec
[  3] 51.0-52.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 52.0-53.0 sec    568 KBytes  4.66 Mbits/sec
[  3] 53.0-54.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 54.0-55.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 55.0-56.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 56.0-57.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 57.0-58.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 58.0-59.0 sec    975 KBytes  7.99 Mbits/sec
[  3] 59.0-60.0 sec  1.06 MBytes  8.87 Mbits/sec
[  3]  0.0-60.0 sec  31.4 MBytes  4.39 Mbits/sec
[  3] Sent 22431 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  4.439 ms 1430/22431 (6.4%)

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	5	 3	1	 1	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.8 port 34275 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    297 KBytes  2.43 Mbits/sec
[  3]  1.0- 2.0 sec    426 KBytes  3.49 Mbits/sec
[  3]  2.0- 3.0 sec    767 KBytes  6.28 Mbits/sec
[  3]  3.0- 4.0 sec  1.02 MBytes  8.60 Mbits/sec
[  3]  4.0- 5.0 sec  1.33 MBytes  11.1 Mbits/sec
[  3]  5.0- 6.0 sec  1.16 MBytes  9.71 Mbits/sec
[  3]  6.0- 7.0 sec    189 KBytes  1.55 Mbits/sec
[  3]  7.0- 8.0 sec    237 KBytes  1.94 Mbits/sec
[  3]  8.0- 9.0 sec    568 KBytes  4.66 Mbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 11.0-12.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 12.0-13.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 13.0-14.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 14.0-15.0 sec    823 KBytes  6.74 Mbits/sec
[  3] 15.0-16.0 sec  1.06 MBytes  8.93 Mbits/sec
[  3] 16.0-17.0 sec  1.01 MBytes  8.47 Mbits/sec
[  3] 17.0-18.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 18.0-19.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 19.0-20.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 22.0-23.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 23.0-24.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 24.0-25.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 25.0-26.0 sec  1.01 MBytes  8.47 Mbits/sec
[  3] 26.0-27.0 sec  1.29 MBytes  10.8 Mbits/sec
[  3] 27.0-28.0 sec  1.46 MBytes  12.3 Mbits/sec
[  3] 28.0-29.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 29.0-30.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 30.0-31.0 sec    568 KBytes  4.66 Mbits/sec
[  3] 31.0-32.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 32.0-33.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 33.0-34.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 34.0-35.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 35.0-36.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 36.0-37.0 sec    879 KBytes  7.20 Mbits/sec
[  3] 37.0-38.0 sec  1.13 MBytes  9.46 Mbits/sec
[  3] 38.0-39.0 sec  1.33 MBytes  11.2 Mbits/sec
[  3] 39.0-40.0 sec    306 KBytes  2.50 Mbits/sec
[  3] 40.0-41.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 41.0-42.0 sec    580 KBytes  4.75 Mbits/sec
[  3] 42.0-43.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 43.0-44.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 44.0-45.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 45.0-46.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 46.0-47.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 47.0-48.0 sec  1018 KBytes  8.34 Mbits/sec
[  3] 48.0-49.0 sec  1.31 MBytes  10.9 Mbits/sec
[  3] 49.0-50.0 sec  1.43 MBytes  12.0 Mbits/sec
[  3] 50.0-51.0 sec    297 KBytes  2.43 Mbits/sec
[  3] 51.0-52.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 52.0-53.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 53.0-54.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 54.0-55.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 55.0-56.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 56.0-57.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 57.0-58.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 58.0-59.0 sec    932 KBytes  7.63 Mbits/sec
[  3] 59.0-60.0 sec  1.06 MBytes  8.88 Mbits/sec
[  3]  0.0-60.0 sec  32.7 MBytes  4.57 Mbits/sec
[  3] Sent 23321 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  30.5 MBytes  4.27 Mbits/sec  3.744 ms 1550/23321 (6.6%)

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	2	 25	15	 10	15	 3	0	 0	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.8 port 36709 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    992 KBytes  8.13 Mbits/sec
[  3]  1.0- 2.0 sec  1.35 MBytes  11.4 Mbits/sec
[  3]  2.0- 3.0 sec    191 KBytes  1.56 Mbits/sec
[  3]  3.0- 4.0 sec    474 KBytes  3.88 Mbits/sec
[  3]  4.0- 5.0 sec  94.7 KBytes    776 Kbits/sec
[  3]  5.0- 6.0 sec    436 KBytes  3.58 Mbits/sec
[  3]  6.0- 7.0 sec  1.18 MBytes  9.88 Mbits/sec
[  3]  7.0- 8.0 sec    828 KBytes  6.79 Mbits/sec
[  3]  8.0- 9.0 sec    474 KBytes  3.88 Mbits/sec
[  3]  9.0-10.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 10.0-11.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 11.0-12.0 sec    835 KBytes  6.84 Mbits/sec
[  3] 12.0-13.0 sec  1.38 MBytes  11.6 Mbits/sec
[  3] 13.0-14.0 sec    254 KBytes  2.08 Mbits/sec
[  3] 14.0-15.0 sec    426 KBytes  3.49 Mbits/sec
[  3] 15.0-16.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 16.0-17.0 sec    380 KBytes  3.12 Mbits/sec
[  3] 17.0-18.0 sec  1.11 MBytes  9.29 Mbits/sec
[  3] 18.0-19.0 sec    904 KBytes  7.41 Mbits/sec
[  3] 19.0-20.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 22.0-23.0 sec    805 KBytes  6.60 Mbits/sec
[  3] 23.0-24.0 sec  1.35 MBytes  11.3 Mbits/sec
[  3] 24.0-25.0 sec    340 KBytes  2.79 Mbits/sec
[  3] 25.0-26.0 sec    521 KBytes  4.27 Mbits/sec
[  3] 26.0-27.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 27.0-28.0 sec    333 KBytes  2.73 Mbits/sec
[  3] 28.0-29.0 sec  1.14 MBytes  9.56 Mbits/sec
[  3] 29.0-30.0 sec  1019 KBytes  8.35 Mbits/sec
[  3] 30.0-31.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 31.0-32.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 32.0-33.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 33.0-34.0 sec    726 KBytes  5.95 Mbits/sec
[  3] 34.0-35.0 sec  1.40 MBytes  11.8 Mbits/sec
[  3] 35.0-36.0 sec    392 KBytes  3.21 Mbits/sec
[  3] 36.0-37.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 37.0-38.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 38.0-39.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 39.0-40.0 sec    627 KBytes  5.14 Mbits/sec
[  3] 40.0-41.0 sec  1.17 MBytes  9.78 Mbits/sec
[  3] 41.0-42.0 sec    401 KBytes  3.28 Mbits/sec
[  3] 42.0-43.0 sec    386 KBytes  3.16 Mbits/sec
[  3] 43.0-44.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 44.0-45.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 45.0-46.0 sec    917 KBytes  7.51 Mbits/sec
[  3] 46.0-47.0 sec  1001 KBytes  8.20 Mbits/sec
[  3] 47.0-48.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 48.0-49.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 49.0-50.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 50.0-51.0 sec    626 KBytes  5.13 Mbits/sec
[  3] 51.0-52.0 sec  1.15 MBytes  9.67 Mbits/sec
[  3] 52.0-53.0 sec    462 KBytes  3.79 Mbits/sec
[  3] 53.0-54.0 sec    426 KBytes  3.49 Mbits/sec
[  3] 54.0-55.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 55.0-56.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 56.0-57.0 sec    913 KBytes  7.48 Mbits/sec
[  3] 57.0-58.0 sec  1.05 MBytes  8.81 Mbits/sec
[  3] 58.0-59.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 59.0-60.0 sec    240 KBytes  1.96 Mbits/sec
[  3]  0.0-60.3 sec  32.2 MBytes  4.48 Mbits/sec
[  3] Sent 22943 datagrams
[  3] Server Report:
[  3]  0.0-60.7 sec  29.7 MBytes  4.10 Mbits/sec  40.016 ms 1775/22943 (7.7%)

----

5413
------

PID tuning test started at Tue Dec 4 23:57:15 EET 2007

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	15	 3	0	 0	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.7 port 41135 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    683 KBytes  5.60 Mbits/sec
[  3]  1.0- 2.0 sec    983 KBytes  8.06 Mbits/sec
[  3]  2.0- 3.0 sec  1.30 MBytes  10.9 Mbits/sec
[  3]  3.0- 4.0 sec  1.41 MBytes  11.9 Mbits/sec
[  3]  4.0- 5.0 sec    690 KBytes  5.66 Mbits/sec
[  3]  5.0- 6.0 sec    237 KBytes  1.94 Mbits/sec
[  3]  6.0- 7.0 sec    474 KBytes  3.88 Mbits/sec
[  3]  7.0- 8.0 sec    584 KBytes  4.79 Mbits/sec
[  3]  8.0- 9.0 sec  94.7 KBytes    776 Kbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 11.0-12.0 sec    617 KBytes  5.06 Mbits/sec
[  3] 12.0-13.0 sec    924 KBytes  7.57 Mbits/sec
[  3] 13.0-14.0 sec  1.29 MBytes  10.8 Mbits/sec
[  3] 14.0-15.0 sec  1.57 MBytes  13.1 Mbits/sec
[  3] 15.0-16.0 sec  1.18 MBytes  9.87 Mbits/sec
[  3] 16.0-17.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 17.0-18.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 18.0-19.0 sec    577 KBytes  4.73 Mbits/sec
[  3] 19.0-20.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 20.0-21.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 21.0-22.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 22.0-23.0 sec    568 KBytes  4.66 Mbits/sec
[  3] 23.0-24.0 sec    968 KBytes  7.93 Mbits/sec
[  3] 24.0-25.0 sec  1.28 MBytes  10.7 Mbits/sec
[  3] 25.0-26.0 sec  1.57 MBytes  13.2 Mbits/sec
[  3] 26.0-27.0 sec  1.19 MBytes  10.0 Mbits/sec
[  3] 27.0-28.0 sec    241 KBytes  1.98 Mbits/sec
[  3] 28.0-29.0 sec    428 KBytes  3.50 Mbits/sec
[  3] 29.0-30.0 sec    620 KBytes  5.08 Mbits/sec
[  3] 30.0-31.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 31.0-32.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 32.0-33.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 33.0-34.0 sec    616 KBytes  5.05 Mbits/sec
[  3] 34.0-35.0 sec    900 KBytes  7.37 Mbits/sec
[  3] 35.0-36.0 sec  1.26 MBytes  10.5 Mbits/sec
[  3] 36.0-37.0 sec  1.66 MBytes  14.0 Mbits/sec
[  3] 37.0-38.0 sec  1.36 MBytes  11.4 Mbits/sec
[  3] 38.0-39.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 39.0-40.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 40.0-41.0 sec    679 KBytes  5.56 Mbits/sec
[  3] 41.0-42.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 42.0-43.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 43.0-44.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 44.0-45.0 sec    524 KBytes  4.29 Mbits/sec
[  3] 45.0-46.0 sec    926 KBytes  7.59 Mbits/sec
[  3] 46.0-47.0 sec  1.26 MBytes  10.5 Mbits/sec
[  3] 47.0-48.0 sec  1.67 MBytes  14.0 Mbits/sec
[  3] 48.0-49.0 sec  1.39 MBytes  11.6 Mbits/sec
[  3] 49.0-50.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 50.0-51.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 51.0-52.0 sec    474 KBytes  3.88 Mbits/sec
[  3] 52.0-53.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 53.0-54.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 54.0-55.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 55.0-56.0 sec    568 KBytes  4.66 Mbits/sec
[  3] 56.0-57.0 sec    900 KBytes  7.37 Mbits/sec
[  3] 57.0-58.0 sec  1.21 MBytes  10.2 Mbits/sec
[  3] 58.0-59.0 sec  1.67 MBytes  14.0 Mbits/sec
[  3] 59.0-60.0 sec  1.48 MBytes  12.4 Mbits/sec
[  3]  0.0-60.1 sec  41.2 MBytes  5.76 Mbits/sec
[  3] Sent 29394 datagrams
[  3] Server Report:
[  3]  0.0-62.0 sec  38.2 MBytes  5.17 Mbits/sec  122.648 ms 2145/29394 (7.3%)

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	5	 3	0	 1	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.7 port 49566 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    943 KBytes  7.73 Mbits/sec
[  3]  1.0- 2.0 sec  1.13 MBytes  9.49 Mbits/sec
[  3]  2.0- 3.0 sec  1.55 MBytes  13.0 Mbits/sec
[  3]  3.0- 4.0 sec  1.94 MBytes  16.3 Mbits/sec
[  3]  4.0- 5.0 sec    240 KBytes  1.96 Mbits/sec
[  3]  5.0- 6.0 sec    284 KBytes  2.33 Mbits/sec
[  3]  6.0- 7.0 sec    716 KBytes  5.87 Mbits/sec
[  3]  7.0- 8.0 sec    142 KBytes  1.16 Mbits/sec
[  3]  8.0- 9.0 sec  94.7 KBytes    776 Kbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 11.0-12.0 sec    853 KBytes  6.99 Mbits/sec
[  3] 12.0-13.0 sec  1.10 MBytes  9.20 Mbits/sec
[  3] 13.0-14.0 sec  1.56 MBytes  13.1 Mbits/sec
[  3] 14.0-15.0 sec  1.92 MBytes  16.1 Mbits/sec
[  3] 15.0-16.0 sec    326 KBytes  2.67 Mbits/sec
[  3] 16.0-17.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 17.0-18.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 18.0-19.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 19.0-20.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 22.0-23.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 23.0-24.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 24.0-25.0 sec  1.12 MBytes  9.38 Mbits/sec
[  3] 25.0-26.0 sec  1.54 MBytes  12.9 Mbits/sec
[  3] 26.0-27.0 sec  1.94 MBytes  16.3 Mbits/sec
[  3] 27.0-28.0 sec    393 KBytes  3.22 Mbits/sec
[  3] 28.0-29.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 29.0-30.0 sec    672 KBytes  5.50 Mbits/sec
[  3] 30.0-31.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 31.0-32.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 32.0-33.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 33.0-34.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 34.0-35.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 35.0-36.0 sec  1.08 MBytes  9.04 Mbits/sec
[  3] 36.0-37.0 sec  1.55 MBytes  13.0 Mbits/sec
[  3] 37.0-38.0 sec  1.93 MBytes  16.2 Mbits/sec
[  3] 38.0-39.0 sec    369 KBytes  3.02 Mbits/sec
[  3] 39.0-40.0 sec    238 KBytes  1.95 Mbits/sec
[  3] 40.0-41.0 sec    672 KBytes  5.50 Mbits/sec
[  3] 41.0-42.0 sec    240 KBytes  1.96 Mbits/sec
[  3] 42.0-43.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 43.0-44.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 44.0-45.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 45.0-46.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 46.0-47.0 sec  1.06 MBytes  8.93 Mbits/sec
[  3] 47.0-48.0 sec  1.50 MBytes  12.6 Mbits/sec
[  3] 48.0-49.0 sec  1.93 MBytes  16.2 Mbits/sec
[  3] 49.0-50.0 sec    451 KBytes  3.69 Mbits/sec
[  3] 50.0-51.0 sec    237 KBytes  1.94 Mbits/sec
[  3] 51.0-52.0 sec    900 KBytes  7.37 Mbits/sec
[  3] 52.0-53.0 sec    297 KBytes  2.43 Mbits/sec
[  3] 53.0-54.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 54.0-55.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 55.0-56.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 56.0-57.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 57.0-58.0 sec  1.07 MBytes  8.98 Mbits/sec
[  3] 58.0-59.0 sec  1.47 MBytes  12.4 Mbits/sec
[  3] 59.0-60.0 sec  1.90 MBytes  16.0 Mbits/sec
[  3]  0.0-60.0 sec  42.2 MBytes  5.89 Mbits/sec
[  3] Sent 30077 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  39.6 MBytes  5.54 Mbits/sec  1.989 ms 1813/30077 (6%)

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	1	 25	15	 10	5	 3	1	 1	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.7 port 54622 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec    825 KBytes  6.76 Mbits/sec
[  3]  1.0- 2.0 sec  1.08 MBytes  9.02 Mbits/sec
[  3]  2.0- 3.0 sec  1.49 MBytes  12.5 Mbits/sec
[  3]  3.0- 4.0 sec  1.90 MBytes  15.9 Mbits/sec
[  3]  4.0- 5.0 sec    511 KBytes  4.19 Mbits/sec
[  3]  5.0- 6.0 sec    189 KBytes  1.55 Mbits/sec
[  3]  6.0- 7.0 sec    666 KBytes  5.46 Mbits/sec
[  3]  7.0- 8.0 sec    289 KBytes  2.36 Mbits/sec
[  3]  8.0- 9.0 sec  94.7 KBytes    776 Kbits/sec
[  3]  9.0-10.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 10.0-11.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 11.0-12.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 12.0-13.0 sec  1.05 MBytes  8.81 Mbits/sec
[  3] 13.0-14.0 sec  1.48 MBytes  12.4 Mbits/sec
[  3] 14.0-15.0 sec  1.86 MBytes  15.6 Mbits/sec
[  3] 15.0-16.0 sec    553 KBytes  4.53 Mbits/sec
[  3] 16.0-17.0 sec    191 KBytes  1.56 Mbits/sec
[  3] 17.0-18.0 sec    853 KBytes  6.99 Mbits/sec
[  3] 18.0-19.0 sec    379 KBytes  3.10 Mbits/sec
[  3] 19.0-20.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 20.0-21.0 sec    144 KBytes  1.18 Mbits/sec
[  3] 21.0-22.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 22.0-23.0 sec    722 KBytes  5.92 Mbits/sec
[  3] 23.0-24.0 sec  1.02 MBytes  8.56 Mbits/sec
[  3] 24.0-25.0 sec  1.46 MBytes  12.3 Mbits/sec
[  3] 25.0-26.0 sec  1.83 MBytes  15.4 Mbits/sec
[  3] 26.0-27.0 sec    678 KBytes  5.55 Mbits/sec
[  3] 27.0-28.0 sec    145 KBytes  1.19 Mbits/sec
[  3] 28.0-29.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 29.0-30.0 sec    474 KBytes  3.88 Mbits/sec
[  3] 30.0-31.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 31.0-32.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 32.0-33.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 33.0-34.0 sec    719 KBytes  5.89 Mbits/sec
[  3] 34.0-35.0 sec  1.02 MBytes  8.58 Mbits/sec
[  3] 35.0-36.0 sec  1.43 MBytes  12.0 Mbits/sec
[  3] 36.0-37.0 sec  1.82 MBytes  15.2 Mbits/sec
[  3] 37.0-38.0 sec    725 KBytes  5.94 Mbits/sec
[  3] 38.0-39.0 sec  96.2 KBytes    788 Kbits/sec
[  3] 39.0-40.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 40.0-41.0 sec    521 KBytes  4.27 Mbits/sec
[  3] 41.0-42.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 42.0-43.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 43.0-44.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 44.0-45.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 45.0-46.0 sec  1.01 MBytes  8.49 Mbits/sec
[  3] 46.0-47.0 sec  1.39 MBytes  11.6 Mbits/sec
[  3] 47.0-48.0 sec  1.85 MBytes  15.5 Mbits/sec
[  3] 48.0-49.0 sec    877 KBytes  7.19 Mbits/sec
[  3] 49.0-50.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 50.0-51.0 sec    850 KBytes  6.96 Mbits/sec
[  3] 51.0-52.0 sec    762 KBytes  6.24 Mbits/sec
[  3] 52.0-53.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 53.0-54.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 54.0-55.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 55.0-56.0 sec    663 KBytes  5.43 Mbits/sec
[  3] 56.0-57.0 sec  1.01 MBytes  8.44 Mbits/sec
[  3] 57.0-58.0 sec  1.36 MBytes  11.4 Mbits/sec
[  3] 58.0-59.0 sec  1.81 MBytes  15.2 Mbits/sec
[  3] 59.0-60.0 sec    995 KBytes  8.15 Mbits/sec
[  3]  0.0-60.5 sec  43.8 MBytes  6.07 Mbits/sec
[  3] Sent 31217 datagrams
[  3] Server Report:
[  3]  0.0-61.7 sec  42.0 MBytes  5.72 Mbits/sec  52.465 ms 1226/31217 (3.9%)

----

rc_imul	rc_idiv	rc_pf	rc_p	rc_i	rc_d	rc_sm_s	rc_sh_s	rc_sh_d
1	2	 25	15	 10	15	 3	0	 0	
------------------------------------------------------------
Client connecting to 192.168.254.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:   106 KByte (default)
------------------------------------------------------------
[  3] local 192.168.254.7 port 44058 connected with 192.168.254.1 port 5001
[  3]  0.0- 1.0 sec  1.80 MBytes  15.1 Mbits/sec
[  3]  1.0- 2.0 sec  96.2 KBytes    788 Kbits/sec
[  3]  2.0- 3.0 sec    734 KBytes  6.01 Mbits/sec
[  3]  3.0- 4.0 sec  94.7 KBytes    776 Kbits/sec
[  3]  4.0- 5.0 sec    521 KBytes  4.27 Mbits/sec
[  3]  5.0- 6.0 sec  1.33 MBytes  11.2 Mbits/sec
[  3]  6.0- 7.0 sec  1.11 MBytes  9.33 Mbits/sec
[  3]  7.0- 8.0 sec    189 KBytes  1.55 Mbits/sec
[  3]  8.0- 9.0 sec    142 KBytes  1.16 Mbits/sec
[  3]  9.0-10.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 10.0-11.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 11.0-12.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 12.0-13.0 sec  1.22 MBytes  10.2 Mbits/sec
[  3] 13.0-14.0 sec  1.32 MBytes  11.0 Mbits/sec
[  3] 14.0-15.0 sec    339 KBytes  2.78 Mbits/sec
[  3] 15.0-16.0 sec  1.03 MBytes  8.68 Mbits/sec
[  3] 16.0-17.0 sec  1.20 MBytes  10.1 Mbits/sec
[  3] 17.0-18.0 sec  1.29 MBytes  10.8 Mbits/sec
[  3] 18.0-19.0 sec    144 KBytes  1.18 Mbits/sec
[  3] 19.0-20.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 20.0-21.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 21.0-22.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 22.0-23.0 sec    758 KBytes  6.21 Mbits/sec
[  3] 23.0-24.0 sec  1.54 MBytes  12.9 Mbits/sec
[  3] 24.0-25.0 sec    666 KBytes  5.46 Mbits/sec
[  3] 25.0-26.0 sec    627 KBytes  5.14 Mbits/sec
[  3] 26.0-27.0 sec    332 KBytes  2.72 Mbits/sec
[  3] 27.0-28.0 sec    769 KBytes  6.30 Mbits/sec
[  3] 28.0-29.0 sec  1.48 MBytes  12.4 Mbits/sec
[  3] 29.0-30.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 30.0-31.0 sec    873 KBytes  7.15 Mbits/sec
[  3] 31.0-32.0 sec    521 KBytes  4.27 Mbits/sec
[  3] 32.0-33.0 sec  1.08 MBytes  9.09 Mbits/sec
[  3] 33.0-34.0 sec  1.54 MBytes  12.9 Mbits/sec
[  3] 34.0-35.0 sec    238 KBytes  1.95 Mbits/sec
[  3] 35.0-36.0 sec  1013 KBytes  8.30 Mbits/sec
[  3] 36.0-37.0 sec    711 KBytes  5.82 Mbits/sec
[  3] 37.0-38.0 sec  1.51 MBytes  12.7 Mbits/sec
[  3] 38.0-39.0 sec    722 KBytes  5.92 Mbits/sec
[  3] 39.0-40.0 sec    533 KBytes  4.36 Mbits/sec
[  3] 40.0-41.0 sec    637 KBytes  5.22 Mbits/sec
[  3] 41.0-42.0 sec  1.08 MBytes  9.08 Mbits/sec
[  3] 42.0-43.0 sec  1.59 MBytes  13.3 Mbits/sec
[  3] 43.0-44.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 44.0-45.0 sec    284 KBytes  2.33 Mbits/sec
[  3] 45.0-46.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 46.0-47.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 47.0-48.0 sec    992 KBytes  8.13 Mbits/sec
[  3] 48.0-49.0 sec  1.72 MBytes  14.4 Mbits/sec
[  3] 49.0-50.0 sec  94.7 KBytes    776 Kbits/sec
[  3] 50.0-51.0 sec    189 KBytes  1.55 Mbits/sec
[  3] 51.0-52.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 52.0-53.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 53.0-54.0 sec    900 KBytes  7.37 Mbits/sec
[  3] 54.0-55.0 sec  1.74 MBytes  14.6 Mbits/sec
[  3] 55.0-56.0 sec    251 KBytes  2.06 Mbits/sec
[  3] 56.0-57.0 sec    191 KBytes  1.56 Mbits/sec
[  3] 57.0-58.0 sec    202 KBytes  1.66 Mbits/sec
[  3] 58.0-59.0 sec    142 KBytes  1.16 Mbits/sec
[  3] 59.0-60.0 sec    853 KBytes  6.99 Mbits/sec
[  3]  0.0-60.0 sec  40.3 MBytes  5.63 Mbits/sec
[  3] Sent 28732 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  39.0 MBytes  5.44 Mbits/sec  4.127 ms  939/28732 (3.3%)

----

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 22:05               ` Nick Kossifidis
@ 2007-12-05  7:49                 ` Holger Schurig
  2007-12-05  9:04                   ` Mattias Nissler
  2007-12-05  9:52                   ` Stefano Brivio
  0 siblings, 2 replies; 34+ messages in thread
From: Holger Schurig @ 2007-12-05  7:49 UTC (permalink / raw)
  To: linux-wireless
  Cc: Nick Kossifidis, Stefano Brivio, Mattias Nissler,
	John W. Linville, Johannes Berg

On Tuesday 04 December 2007 23:05:28 Nick Kossifidis wrote:
> [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  3.242 ms
> [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  4.439 ms
> [  3]  0.0-60.0 sec  32.7 MBytes  4.57 Mbits/sec
...


Could it be the case that if we test the PID controller such way,
then we optimize for throughtput in a scenario like "laptop sits 
next the the AP".

Or, in other words: if we put the AP 80m away and then try the 
test, would the same PID parameters that yielded high MB/s rates 
now still keep us a sane (for that distance!) connection?

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-05  7:49                 ` Holger Schurig
@ 2007-12-05  9:04                   ` Mattias Nissler
  2007-12-05  9:52                   ` Stefano Brivio
  1 sibling, 0 replies; 34+ messages in thread
From: Mattias Nissler @ 2007-12-05  9:04 UTC (permalink / raw)
  To: Holger Schurig
  Cc: linux-wireless, Nick Kossifidis, Stefano Brivio,
	John W. Linville, Johannes Berg


On Wed, 2007-12-05 at 08:49 +0100, Holger Schurig wrote:
> On Tuesday 04 December 2007 23:05:28 Nick Kossifidis wrote:
> > [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  3.242 ms
> > [  3]  0.0-60.0 sec  29.4 MBytes  4.11 Mbits/sec  4.439 ms
> > [  3]  0.0-60.0 sec  32.7 MBytes  4.57 Mbits/sec
> ...
> 
> 
> Could it be the case that if we test the PID controller such way,
> then we optimize for throughtput in a scenario like "laptop sits 
> next the the AP".
> 
> Or, in other words: if we put the AP 80m away and then try the 
> test, would the same PID parameters that yielded high MB/s rates 
> now still keep us a sane (for that distance!) connection?

Good question. The important parameter here is the failed frames
precentage target value. If we're sitting next to the AP, the percentage
of failed frames will be very low, so the PID controller won't ever be
able to tune the TX rate to increase the failed frames percentage to the
target value. So this is not the right test case for tuning PID rate
control parameters. It'd be interesting to find out about the failed
frames percentage target value that gives us the best throughput. And
then do this experiment several times for different levels of distance
(or noise). Then see whether the optimal value is constant or not.

At the moment, I'm still cleaning up the rate control code. I also plan
to add some debugfs support, so we can retrieve the relevant data from
the kernel and make graphs from them. Only when this is done, I'm gonna
resume tuning parameters.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-05  7:49                 ` Holger Schurig
  2007-12-05  9:04                   ` Mattias Nissler
@ 2007-12-05  9:52                   ` Stefano Brivio
  2007-12-05 12:13                     ` rc80211-pid: some tuning test results Stefano Brivio
  1 sibling, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-05  9:52 UTC (permalink / raw)
  To: Holger Schurig
  Cc: linux-wireless, Nick Kossifidis, Mattias Nissler,
	John W. Linville, Johannes Berg

On Wed, 5 Dec 2007 08:49:46 +0100
Holger Schurig <hs4233@mail.mn-solutions.de> wrote:

> Or, in other words: if we put the AP 80m away and then try the 
> test, would the same PID parameters that yielded high MB/s rates 
> now still keep us a sane (for that distance!) connection?

Theoretically, a properly tuned PID controller should act well in both
scenarios. The problem here is that we need testing in worse scenarios. I
just detached the antenna from my AP, this decreases the signal level by
some 20-23dB. Will do some tests.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04 17:45           ` Mattias Nissler
@ 2007-12-05 10:16             ` Johannes Berg
  0 siblings, 0 replies; 34+ messages in thread
From: Johannes Berg @ 2007-12-05 10:16 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Tomas Winkler, Stefano Brivio, linux-wireless, John W. Linville

[-- Attachment #1: Type: text/plain, Size: 233 bytes --]


> Ok, sounds good. What is the overall strategy for deciding what goes
> into nl80211, what into sysfs?

None really, I tend to think it should all be in cfg80211 and then maybe
Luis will put it into configfs too.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread

* rc80211-pid: some tuning test results
  2007-12-05  9:52                   ` Stefano Brivio
@ 2007-12-05 12:13                     ` Stefano Brivio
  2007-12-08  3:42                       ` Stefano Brivio
  0 siblings, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-05 12:13 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Holger Schurig, linux-wireless, Nick Kossifidis, Mattias Nissler,
	John W. Linville, Johannes Berg

Here are some results from recent tests. Each test lasted for 30 seconds.
Signal and noise figures have been provided by a prism2 card with an almost
isotropic antenna. Throughput tests have been made with a bcm4309 card, b43
driver.

Scenarios:
#1: very weak signal (ranging from -88 to -86dBm), low noise (-98dBm)
mostly produced by other devices in the area. High multi-path reflection
provided by grounded metal boxes between the two STAs. The b43 device has
been moved alternatively by 2cm to left and right, with an approximate
speed of 0.5cm/s.
#2: weak signal (-81dBm), very high noise (-86dBm) produced by a microwave
oven cooking vegetables at 750W. Multi-path reflection and moving as above.
#3: almost optimal conditions. Good signal (-43dBm) and low noise (-98dBm).
No multi-path reflection. Only moving as above.

Results: [all throughputs are in Mbps]
imul idiv   pf    p    i    d  sm_s sh_s sh_d   thr1   thr2   thr3
   1    8   25   15   10   20     3    1    1  1.300  0.055  14.40
   1    8   25   15   10   20     3    0    1  0.108  0.473  16.69
   1    8   25   15   10   20     3    0    0  0.745  0.190  12.17
   1    8   15   15   10   20     3    1    1  1.190  0.249  17.51
   1    8   15   15   10   20     3    0    1  0.624  0.134  13.80
   1    8   15   15   10   20     3    0    0  0.912  0.419  12.02
   1    8    5   15   10   20     3    1    1  1.370  1.180  12.06
   1    8    5   15   10   20     3    0    1  0.875  0.264  11.92
   1    8    5   15   10   20     3    0    0  0.739  0.971  11.76

   1    8   25   15   10   15     3    1    1  1.170  0.099  18.04
   1    8   25   15   10   15     3    0    1  0.797  0.296  11.93
   1    8   25   15   10   15     3    0    0  0.617  0.222  11.55
   1    8   15   15   10   15     3    1    1  1.690  1.380  11.19
   1    8   15   15   10   15     3    0    1  1.030  0.205  16.80
   1    8   15   15   10   15     3    0    0  1.190  0.062  17.07
   1    8    5   15   10   15     3    1    1  2.450  0.221  12.46
   1    8    5   15   10   15     3    0    1  1.610  0.193  18.16
   1    8    5   15   10   15     3    0    0  2.320  0.349  17.94

   1    8   25   15   15   20     3    1    1  1.690  0.790  12.38
   1    8   25   15   15   20     3    0    1  0.968  0.918  17.50
   1    8   25   15   15   20     3    0    0  1.160  0.134  11.59
   1    8   15   15   15   20     3    1    1  1.670  0.223  16.83
   1    8   15   15   15   20     3    0    1  0.734  0.164  12.28
   1    8   15   15   15   20     3    0    0  1.740  0.316  11.94
   1    8    5   15   15   20     3    1    1  0.886  0.620  17.00
   1    8    5   15   15   20     3    0    1  0.567  0.212  18.11
   1    8    5   15   15   20     3    0    0  1.080  0.089  12.13

   1    8   25   15   15   15     3    1    1  0.627  0.458  14.00
   1    8   25   15   15   15     3    0    1  0.521  0.617  12.07
   1    8   25   15   15   15     3    0    0  1.180  0.098  11.82
   1    8   15   15   15   15     3    1    1  1.450  0.366  17.40
   1    8   15   15   15   15     3    0    1  1.190  0.724  13.53
   1    8   15   15   15   15     3    0    0  1.250  0.627  18.28
   1    8    5   15   15   15     3    1    1  0.997  0.379  13.59
   1    8    5   15   15   15     3    0    1  0.550  0.240  11.68
   1    8    5   15   15   15     3    0    0  1.340  0.136  17.37


The second block of results looks good. There we can find the first and
third best results for scenario #1, best result for scenario #2, second
and fourth best for #3. It looks like Mattias's first guess for PID
coefficients was actually very accurate.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: rc80211-pid: some tuning test results
  2007-12-05 12:13                     ` rc80211-pid: some tuning test results Stefano Brivio
@ 2007-12-08  3:42                       ` Stefano Brivio
  2007-12-08 10:39                         ` Mattias Nissler
  0 siblings, 1 reply; 34+ messages in thread
From: Stefano Brivio @ 2007-12-08  3:42 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Holger Schurig, linux-wireless, Nick Kossifidis, Mattias Nissler,
	John W. Linville, Johannes Berg

I run further tests. It looks like I found out the optimal parameters for
minimizing latency or maximizing throughput or maximizing reliability.

Best throughput:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
1       8        11     14       10     12       3      0        1

Best latency:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
1       8        15     12       8      16       2      1        1

Best reliability:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
1       8        4      15       8      15       3      0        0

While a general good setup looks to be:

rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
1       8        10     15       9      15       3      0        1

I would then adopt a system like the one outlined below in order to take
into account userspace parameters.

We have Three userspace parameters, ranging from 0 (don't care) to 5
(care the most). I don't think it makes any sense to have more granularity
here.

Starting from:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
1       8        10     15       9      15       3      0        1

We add:
For every threshold point:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
		+0.2	-0.2	+0.2	-0.6

latency points:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
		+1	-0.6	-0.2	+0.2	-0.2	+0.2

reliability points:
rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
		-1.2		-0.2				-0.2

I'll now try to implement this sorting out the fixed point calculation
issues.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control
  2007-12-04  1:41             ` Stefano Brivio
  2007-12-04  8:15               ` Mattias Nissler
  2007-12-04 22:05               ` Nick Kossifidis
@ 2007-12-08  9:45               ` Stefano Brivio
  2 siblings, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-08  9:45 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Nick Kossifidis, Mattias Nissler, linux-wireless,
	John W. Linville, Johannes Berg

On Tue, 4 Dec 2007 02:41:46 +0100
Stefano Brivio <stefano.brivio@polimi.it> wrote:

> -		err_avg = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
> +		err_avg = srctrl->err_avg_sc >> modparam_rc_sh_s;
							     ^

>  		srctrl->err_avg_sc = srctrl->err_avg_sc - err_avg + err_prop;
> -		err_int = srctrl->err_avg_sc >> RATE_CONTROL_SMOOTHING_SHIFT;
> +		err_int = srctrl->err_avg_sc >> modparam_rc_sh_s;
							     ^

Sorry, I forgot to resend. Will send another patch soon so I won't bother.


-- 
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: rc80211-pid: some tuning test results
  2007-12-08  3:42                       ` Stefano Brivio
@ 2007-12-08 10:39                         ` Mattias Nissler
  2007-12-08 11:17                           ` Stefano Brivio
  0 siblings, 1 reply; 34+ messages in thread
From: Mattias Nissler @ 2007-12-08 10:39 UTC (permalink / raw)
  To: Stefano Brivio
  Cc: Holger Schurig, linux-wireless, Nick Kossifidis,
	John W. Linville, Johannes Berg


On Sat, 2007-12-08 at 04:42 +0100, Stefano Brivio wrote:
> I run further tests. It looks like I found out the optimal parameters for
> minimizing latency or maximizing throughput or maximizing reliability.

Great. I haven't had much time and probably cannot find more time this
weekend, so I still haven't done much testing.

> 
> Best throughput:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        11     14       10     12       3      0        1
> 
> Best latency:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        15     12       8      16       2      1        1
> 
> Best reliability:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        4      15       8      15       3      0        0
> 
> While a general good setup looks to be:
> 
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        10     15       9      15       3      0        1
> 
> I would then adopt a system like the one outlined below in order to take
> into account userspace parameters.
> 
> We have Three userspace parameters, ranging from 0 (don't care) to 5
> (care the most). I don't think it makes any sense to have more granularity
> here.

Why wouldn't you let userspace set the raw parameters directly? The
complicated scheme you propose prevents us to tell users/testers to
"change the X parameter to see it gives better Y results". If you give
access to the raw parameters, people can still tweak and tune them if
the rate control fails for special situations (e.g. hardware that cannot
report whether a frame was only retried or totally failed, special noise
situations, whatever).

Furthermore, you can still have the simplified scheme by providing a
userspace tool (maybe even add it to iw, once we have an interface) that
takes the input, calculates the raw parameters as below and writes the
results to the kernel.

Bottom line: This thing complicates the kernel, makes the thing less
understandable for people who now what a PID controller is, complicates
future tweaking and tuning of the (default) parameters and moreover
could also be implemented in userspace. So my vote is against it.

> 
> Starting from:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 1       8        10     15       9      15       3      0        1
> 
> We add:
> For every threshold point:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		+0.2	-0.2	+0.2	-0.6
> 
> latency points:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		+1	-0.6	-0.2	+0.2	-0.2	+0.2
> 
> reliability points:
> rc_imul rc_idiv rc_pf   rc_p    rc_i    rc_d    rc_sm_s rc_sh_s rc_sh_d
> 		-1.2		-0.2				-0.2
> 
> I'll now try to implement this sorting out the fixed point calculation
> issues.

I've done a lot of code cleaning, maybe you want to base your patches on
that. There's more to come, but I'll send them so you have something to
start.

Mattias


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: rc80211-pid: some tuning test results
  2007-12-08 10:39                         ` Mattias Nissler
@ 2007-12-08 11:17                           ` Stefano Brivio
  0 siblings, 0 replies; 34+ messages in thread
From: Stefano Brivio @ 2007-12-08 11:17 UTC (permalink / raw)
  To: Mattias Nissler
  Cc: Holger Schurig, linux-wireless, Nick Kossifidis,
	John W. Linville, Johannes Berg

On Sat, 08 Dec 2007 11:39:58 +0100
Mattias Nissler <mattias.nissler@gmx.de> wrote:

> Why wouldn't you let userspace set the raw parameters directly? The
> complicated scheme you propose prevents us to tell users/testers to
> "change the X parameter to see it gives better Y results". If you give
> access to the raw parameters, people can still tweak and tune them if
> the rate control fails for special situations (e.g. hardware that cannot
> report whether a frame was only retried or totally failed, special noise
> situations, whatever).
> 
> Furthermore, you can still have the simplified scheme by providing a
> userspace tool (maybe even add it to iw, once we have an interface) that
> takes the input, calculates the raw parameters as below and writes the
> results to the kernel.
> 
> Bottom line: This thing complicates the kernel, makes the thing less
> understandable for people who now what a PID controller is, complicates
> future tweaking and tuning of the (default) parameters and moreover
> could also be implemented in userspace. So my vote is against it.

I'm not so sure about this. I think that this is really specific to the
algorithm, so it looked like a natural choice to put this into the kernel.
But your points make a lot of sense. I should probably remove this from
here and send patches to iw.

> I've done a lot of code cleaning, maybe you want to base your patches on
> that. There's more to come, but I'll send them so you have something to
> start.

Me too I started to clean up the code, nevertheless if you send them it
will be useful. Thank you.


--
Ciao
Stefano

^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2007-12-08 11:23 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-02 19:05 [RFC][PATCH] mac80211: Use PID controller for TX rate control Mattias Nissler
2007-12-03  3:16 ` Stefano Brivio
2007-12-03  3:26   ` Stefano Brivio
2007-12-03 11:03   ` Mattias Nissler
2007-12-03 11:21     ` Tomas Winkler
2007-12-03 11:31       ` Mattias Nissler
2007-12-04 13:40         ` Johannes Berg
2007-12-04 17:45           ` Mattias Nissler
2007-12-05 10:16             ` Johannes Berg
2007-12-04 17:48           ` Stefano Brivio
2007-12-03 11:58       ` Stefano Brivio
2007-12-03 11:54     ` Stefano Brivio
2007-12-03 11:59       ` Mattias Nissler
2007-12-03 12:06         ` Stefano Brivio
2007-12-03 22:42           ` Nick Kossifidis
2007-12-03 23:36             ` Mattias Nissler
2007-12-04  1:41             ` Stefano Brivio
2007-12-04  8:15               ` Mattias Nissler
2007-12-04 10:01                 ` Stefano Brivio
2007-12-04 17:40                   ` Mattias Nissler
2007-12-04 17:57                     ` Stefano Brivio
2007-12-04 18:33                       ` Mattias Nissler
2007-12-04 18:40                         ` Stefano Brivio
2007-12-04 20:50                     ` Holger Schurig
2007-12-04 20:57                       ` Mattias Nissler
2007-12-04 22:05               ` Nick Kossifidis
2007-12-05  7:49                 ` Holger Schurig
2007-12-05  9:04                   ` Mattias Nissler
2007-12-05  9:52                   ` Stefano Brivio
2007-12-05 12:13                     ` rc80211-pid: some tuning test results Stefano Brivio
2007-12-08  3:42                       ` Stefano Brivio
2007-12-08 10:39                         ` Mattias Nissler
2007-12-08 11:17                           ` Stefano Brivio
2007-12-08  9:45               ` [RFC][PATCH] mac80211: Use PID controller for TX rate control Stefano Brivio

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.