2007-12-02 19:05:35

by Mattias Nissler

[permalink] [raw]
Subject: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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 <[email protected]>
---
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



2007-12-03 12:09:49

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Mon, 03 Dec 2007 12:59:04 +0100
Mattias Nissler <[email protected]> wrote:

> On Mon, 2007-12-03 at 12:54 +0100, Stefano Brivio wrote:
> > On Mon, 03 Dec 2007 12:03:00 +0100
> > Mattias Nissler <[email protected]> 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

2007-12-03 22:42:41

by Nick Kossifidis

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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

2007-12-04 22:05:29

by Nick Kossifidis

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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

2007-12-04 20:49:39

by Holger Schurig

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

> 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.

2007-12-04 17:45:50

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


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


2007-12-08 10:40:02

by Mattias Nissler

[permalink] [raw]
Subject: Re: rc80211-pid: some tuning test results


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


2007-12-05 09:04:07

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


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


2007-12-05 12:17:52

by Stefano Brivio

[permalink] [raw]
Subject: rc80211-pid: some tuning test results

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

2007-12-04 08:15:07

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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


2007-12-04 18:44:46

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Tue, 04 Dec 2007 19:33:06 +0100
Mattias Nissler <[email protected]> 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

2007-12-04 17:53:00

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Tue, 04 Dec 2007 14:40:23 +0100
Johannes Berg <[email protected]> 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

2007-12-03 23:36:09

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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



2007-12-03 11:59:07

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


On Mon, 2007-12-03 at 12:54 +0100, Stefano Brivio wrote:
> On Mon, 03 Dec 2007 12:03:00 +0100
> Mattias Nissler <[email protected]> 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


2007-12-04 01:45:53

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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

2007-12-08 11:23:37

by Stefano Brivio

[permalink] [raw]
Subject: Re: rc80211-pid: some tuning test results

On Sat, 08 Dec 2007 11:39:58 +0100
Mattias Nissler <[email protected]> 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

2007-12-04 20:57:53

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


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


2007-12-05 09:57:07

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Wed, 5 Dec 2007 08:49:46 +0100
Holger Schurig <[email protected]> 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

2007-12-05 07:49:30

by Holger Schurig

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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?

2007-12-05 10:16:39

by Johannes Berg

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


> 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


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part

2007-12-03 03:19:52

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Sun, 02 Dec 2007 20:05:31 +0100
Mattias Nissler <[email protected]> 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

2007-12-04 10:05:48

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Tue, 04 Dec 2007 09:15:03 +0100
Mattias Nissler <[email protected]> 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

2007-12-04 18:01:43

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Tue, 04 Dec 2007 18:40:47 +0100
Mattias Nissler <[email protected]> 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: <[email protected]>, on linux-wireless.


--
Ciao
Stefano

2007-12-03 11:21:22

by Tomas Winkler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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 <[email protected]> wrote:
>
> On Mon, 2007-12-03 at 04:16 +0100, Stefano Brivio wrote:
> > On Sun, 02 Dec 2007 20:05:31 +0100
> > Mattias Nissler <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

2007-12-03 11:31:59

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


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


2007-12-04 17:40:51

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


On Tue, 2007-12-04 at 11:01 +0100, Stefano Brivio wrote:
> On Tue, 04 Dec 2007 09:15:03 +0100
> Mattias Nissler <[email protected]> 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


2007-12-03 12:02:26

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Mon, 3 Dec 2007 13:21:21 +0200
"Tomas Winkler" <[email protected]> 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

2007-12-03 11:59:21

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Mon, 03 Dec 2007 12:03:00 +0100
Mattias Nissler <[email protected]> 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

2007-12-03 03:30:31

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

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

2007-12-03 11:03:04

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


On Mon, 2007-12-03 at 04:16 +0100, Stefano Brivio wrote:
> On Sun, 02 Dec 2007 20:05:31 +0100
> Mattias Nissler <[email protected]> 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


2007-12-08 09:51:39

by Stefano Brivio

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control

On Tue, 4 Dec 2007 02:41:46 +0100
Stefano Brivio <[email protected]> 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

2007-12-08 03:47:53

by Stefano Brivio

[permalink] [raw]
Subject: Re: rc80211-pid: some tuning test results

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

2007-12-04 16:31:56

by Johannes Berg

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


> 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


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part

2007-12-04 18:33:10

by Mattias Nissler

[permalink] [raw]
Subject: Re: [RFC][PATCH] mac80211: Use PID controller for TX rate control


> 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