Re: adaptive rate algorithms and Atheros adaptiveradio

Adaptive Radio (AR) is the Dynamic Turbo feature in this whitepaper: http://atheros.com/pt/whitepapers/atheros_superg_whitepaper.pdf

>From an Atheros press release: "The AR5005GS uses Atheros adaptive radio technology, which actively looks for clear channels and uses them to provide maximum throughput-on-demand for all users."

So, it's nothing more than the 20/40MHz automatic channel width selection you're probably used to with most "108Mbps" 802.11a/g radios.  If 40MHz operation is allowed on the current channel by the regulatory domain, and there are no adjacent radios, it will bump up to 40MHz channel width, otherwise it will stay at 20MHz.  I have no idea if this actually works in madwifi, let alone which branches and HALs may support it, and if it works if any connected clients don't support it (my guess is no).  Data rate and modulation, as minstrel or any other rate selection algorithm determines, aren't affected by AR, and don't conflict with it.  Also I would venture a guess that AR only checks if the adjacent channels are free, and doesn't actually aid in channel selection, although some OEM adverts would lead you to believe otherwise.

-Brian Prodoehl


-----Original Message-----
From: Mohan R [mailto:[email protected]]
Sent: Tue 3/9/2010 1:43 AM
To: 'Pavel Roskin'
Cc: [email protected]
Subject: Re: [Madwifi-users] adaptive rate algorithms and Atheros adaptiveradio
 
Than you very much for your reply.

As suggested by the code comments, I am not sure if the IEEE80211_ATHC_AR
bit is used ONLY for the skipping the frequencies used by radar (especially
in the 5G band). This is an FCC requirement for software controlled radios.

By "adaptive radio" I mean the hardware capabilities built into the Athero's
chipset sets. The chipsets have the following capabilities as per the white
paper available in the Atheros web site.

1. Fast frames (ff) : when enabled hardware aggregates smaller frames into a
single large frame. This reduces the transmit overheads

2. Extended range (XR): increases the receiver sensitivity threshold to -105
dBm. This facilitates data reception from longer ranges

3. Burst: uses SIFS instead of DIFS to reduce transmit time

4. Adaptive radio (ar): supposed to select the optimum mode (turbo, etc),
channel (bundling), data rate, etc and ensure the maximum possible
throughput.

There is no documentation available on how this is achieved. As I said in my
earlier mail this may conflict with the rate adaptation algorithms. It will
be nice to know how both "adaptive radio" and the "adaptive rate algorithms"
can coexist.

Regards,

R.Mohan

-----Original Message-----
From: Pavel Roskin [mailto:[email protected]] 
Sent: Friday, March 05, 2010 8:47 AM
To: MOHAN.R.
Cc: [email protected]
Subject: Re: [Madwifi-users] adaptive rate algorithms and Atheros adaptive
radio

On Thu, 2010-03-04 at 11:46 +0530, MOHAN.R. wrote:

> 1. It is my understanding that the adaptive rate algorithm ( sample,
> minstrel, etc..) is enabled only when the rate is set to auto using
> the iwconfig command. If an explicit rate such as 36M is set, then the
> adaptive rate algorithm is disabled. Is my understanding correct?

That's true.  I know that from the code.  Just search for iv_fixed_rate
under ath_rate to see for yourself.

> 2. Both adaptive rate algorithms as well as Atheros adaptive radio do
> the same job of selecting the best possible data rate over air.

I don't see any references to "adaptive radio" in the code.  If you mean
AMMR (Adaptive Multi Rate Retry), that's just another rate control
algorithm, like sample and minstrel.

> If both are enabled (rate set to auto using iwconfig and ar set to 1 /
> enabled using the iwpriv) will there be a conflict of interests
> between these?

The "ar" parameter ultimately leads to the IEEE80211_ATHC_AR bit, which
is described in net80211/ieee80211.h:

#define IEEE80211_ATHC_AR       0x0010          /* Advanced Radar support */

Apart from the above comment, this is completely undocumented, as far as
I can tell.

-- 
Regards,
Pavel Roskin


The information contained in this electronic message and any attachments to this message are intended for the exclusive 
use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended
 recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy
 all copies of this message and any attachments contained in it.



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Madwifi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-users

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Madwifi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-users