On Friday 24 September 2004 01:20 pm, David Young wrote:
> On Fri, Sep 24, 2004 at 12:01:19PM -0700, Sam Leffler wrote:
> > On Friday 24 September 2004 11:45 am, David Young wrote:
> > > On Thu, Sep 23, 2004 at 05:52:04PM -0700, Sam Leffler wrote:
> > > > The bug is actually that ath_tx_start should check for multicast
> > > > frames and use a rate appropriate for control frames.
> > >
> > > FWIW, ieee80211_rssadapt_choose does what Sam is saying.
> >
> > I chose to make decisions like this in the driver and not in the rate
> > control code since it would have required passing the packet contents in
> > (or at least a reference to the header).  I believe the handling of
> > control+management+mcast frames is well-enough defined to be done outside
> > rate control.  Separately net80211 is lacking some tunable parameters
> > like a fixed/min rate for data frames and/or all frames.
>
> Seems to me that when the network membership is known, we can make a
> smart choice, based on the link adaptation, whether to send multicasts
> and mgmt frames at 1, 2, or greater Mbps.  Apart from beacon frames,
> sending mgmt frames at low bit rates doesn't seem to be a problem,
> but high-throughput multicast apps will suffer.  No?

I didn't say you have to send them at a low rate. The rate to use for control 
(and mcast) frames can be expressed as a fixed value based on the phy and 
current transmit rate.  My existing code does not do that but the necessary 
tables are in place (in the hal).

The key question (to me) is whether or not this decision belongs in the driver 
or in the rate control algorithm.  The rate control support for the ath 
driver does not try to be device-independent so it was easier for me to 
choose to make the decision in the driver.  I may want to revisit this.

	Sam