[Madwifi-users] Re: AW: [Madwifi-devel] Re: rate control algorithms

[Mathieu L. <Mat...@so...>]

On Wed, 2004-08-18 at 13:22, Togg wrote:
> Hi Mathieu,
>=20
> AMRR works fine for me. I think it would be great if one could chose the

Did you perform a few performance comparisons ?

> rate control algorithm through a module parameter to do quick compares e.=
g.

Sam would like to see two modules so you choose to load the amrr module
and then load the madwifi module. I don't have time to do that right now
but I would be happy to review patches which provide this based on my
previous patch which separated the normal madwifi and the amrr
algorithms.

If no one steps to do this, I will see if I can convince a lost intern
to learn kernel programming :) Or I'll just do this if I feel I have a
day to waste (my kernel programming abilities being very limited, I know
it will take me too much time although it is a rather trivial task).

regards,
Mathieu

>=20
> I would agree to adding ammr as default rate control.
>=20
> Regards,
> Togg
>=20
> -----Urspr=C3=BCngliche Nachricht-----
> Von: mad...@li...
> [mailto:mad...@li...] Im Auftrag von Mathieu
> Lacage
> Gesendet: Mittwoch, 18. August 2004 08:00
> An: John Bicket
> Cc: David Young; madwifi; Thierry Turletti; Hossein Manshaei;
> dy...@ne...; car...@us...;
> ro...@am...
> Betreff: Re: [Madwifi-devel] Re: rate control algorithms
>=20
> Hi John,
>=20
> On Tue, 2004-08-17 at 09:47, John Bicket wrote:
>=20
> [snip]
>=20
> > Here is the cdf of how the rate control algorithms did on the links:
> > http://pdos.lcs.mit.edu/~jbicket/rate.g.cdf.eps
> > It seems as through arf consistently performs poorly - it seems that
> > either sticks with bitrates that require many retries (but don't fail
> > often) or it is too sensitive to failures.
>=20
> I wonder how you implemented it. Did you merely add code in
> ath_rx_tasklet to update the ARF counters and ath_tx_start to pick the
> rate ? If you did this and if you are using saturation experiments for
> these results, then I know what is wrong :)
>=20
> What happens is that when you are using saturation, the tx queue of the
> madwifi hardware fills quickly (I measured often 80 to 100 items).  When
> you update the arf counters from ath_tx_tasklet (or ath_processq in the
> latest version of the madwifi driver), you update them with information
> from packets which are at the head of the queue. When you pick the rate
> in ath_tx_start, you configure the rate for the packets at the tail of
> the queue. Needless to say, this will trigger wide oscillations of your
> algorithm which will make it always pick the wrong rate.
>=20
> I wrote a "fix" for that which is, however, rather yucky: it parses the
> hardware transmission queue to update the rate choosen in each packet
> rather than just updating the rate for the packet at the tail of the
> queue. Another fix is to allow only one packet at a time in the queue.
> This is the solution sam tends towards because it has the nice
> side-effect that you can use it to implement multi-rate retry for older
> Atheros hardware. I have not had time to implement this though.
>=20
> Of course, the madwifi algorithm does not really suffer from this
> problem (it has other problems) because it runs from a periodic timer
> whose period is longer than the time most often needed to empty the
> transmission queue.
>=20
> I hope this helps,
>=20
> regards,
> Mathieu
--=20
Mathieu Lacage <mat...@so...>