Hi,

>From now on, would you mind cc'ing freebsd-wireless@freebsd.org on
discussions about this? I'd prefer to have this discussion in public
so everyone can benefit!

On 16 July 2013 20:28, Chenchong Qin <qinchench...@gmail.com> wrote:
> Hi!
>
> I've read your change to ieee80211_[phy amrr] and commited some code to my
> soc repo.

Cool!

> For pre-802.11n, if rts/cts flag is set on retry 0, retries 1, 2, 3 can't be
> used. And if rts/cts flag is not set on retry 0, we take it as a
> non-protected rate series, rts/cts of retries 1, 2, 3 is useless neither.

Right. This is specific to the Atheros hardware that supports this
kind of multi-rate retry.

> So, for non-11n scenario, I clear rts/cts flag of retries 1, 2, 3 and if
> retry 0 enable rts/cts, blank tries 1, 2, 3. Is this logic resonable?

Right. Well, what I think it should be is some kind of hardware
capability that the chip tells the rate control code when it
initialises.

Ie;

* I support multi-rate retry;
* I support RTS for all rate retries (defaulting to the non-11n
behaviour of _EITHER_ multi-rate retry + no RTSCTS, _OR_ single rate
try + RTS/CTS

> As for the 11n stuff for rate control, it seems to happen after lookup of
> rates. Functions in if_ath_tx_ht.c, ie. ath_tx_rate_fill_rcflags and
> ath_buf_set_rate, are called after ath_tx_do_ratelookup. Are we going to
> implement all the same thing in one ieee80211_ratectrl_ functioin, or
> sepreate functions?

Well, what do you think? You're the one tinkering with this. :)

Note that I've done it in a few places;

* I do the rate lookup from ath_rate;
* I then copy that into an ath_rc_series array;
* I then "fix" the rate series up with 11n options - based purely on
the negotiated parameters;
* I convert the ath_rc_series into the HAL series, turning these
options into hardware specific flags.

Now, this means:

* if it's a HT40 AP and STA, I always transmit HT40 - even though I
could in theory choose to transmit HT20;
* if the AP/STA support STBC, I always transmit STBC for MCS 0-7, but
I in theory could choose not to;
* If the AP/STA support short-GI, I always transmit it, even if I may
choose not to;
* etc.

I did that because it's simple. But it may be that we should leave
that up to the rate control module. It may decide to try transmitting
HT20 only frames even though both sides are HT40.

What do you think?



-adrian
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to