I have been hacking at adding 11n awareness to the PHY and rate
control code in net80211 in preparation for "real" 11n awareness in
the rate control code.
The patch is here:
* The rate representation is a single uint8_t which represents the
throughput (pre-11n) or the MCS code (11n)
* The BASIC rate flag is 0x80, and the MCS rate flag is 0x80 - making
a unified representation of "stuff" rather difficult;
* There's no current way for it to return the rest of the 11n
configuration (short-gi, 20/40mhz, stbc, ldpc, etc), which means the
current "result" isn't enough to fully represent an 11n transmit;
* .. same with pre-11n - there's no current way for the rate control
code to say "transmit short preamble" for legacy (11b) versus 11g
What it does:
* adds the 11n PHY tables to ieee80211_phy.c;
* adds 11n packet duration calculation as a new function call;
* adds some new methods in ieee80211_phy.h to access the rate code
information based on the rate index;
* adds checks to ensure that these legacy methods don't get called
with the MCS/BASIC bit set (0x80);
* Modify amrr to use the HT table if the device is HT aware
* Modify the drivers that directly use the node rate table to use the
new phy functions that do it for you, which do sanity checks;
* The drivers now only look up the legacy rates -without- the basic
rate flag, so when they're taught about 11n it is clear what that 0x80
* remove that "pretend I'm 11n, really" crap from iwn_newassoc(), as
now amrr will return 11n rates;
* move the rate/ridx -> iwn plcp table into an inline function that
takes the node and rate, and calculates the plcp to use
* teach it to now use the HT rate from amrr correctly
I've verified this on iwn(4) in STA mode and it's behaving correctly.
AMRR makes some pretty bad 11n decisions but I'm not making it worse.
I'd appreciate any testing that people can give.
I'm going to commit this soon.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"