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