The so called "turbo" mode extensions provided by various vendors
roughly fall into 3 categories
1. MAC extensions such as frame bursting, aggregation, using more
aggressive transmit parameters etc
2. PHY extensions such as using proprietary modulation/coding, MIMO etc
3. RF extensions such as using larger channel width, also sometimes
called channel bonding
All of these have been adequately addressed by 802.11e, WMM and 802.11n
and there exist modes which allow these to be done in a standard
compliant and interoperable manner. In my opinion, the linux wireless
stack would do well to stay away from the proprietary extensions and
thus minimize confusion.
At most, we could allow an API for enable/disable turbo mode which would
allow the specific driver/firmware to do whatever magic it wants under
the hood without polluting the rest of the stack.
Thanks,
Sandesh
-----Original Message-----
From: Tomas Winkler [mailto:[email protected]]
Sent: Monday, June 18, 2007 5:55 PM
To: Johannes Berg
Cc: Sandesh Goel; David Lamparter; linux-wireless
Subject: Re: phy mode, channel -> freq mapping (was RE: more nl80211/iw
tool code comments)
On 6/18/07, Johannes Berg <[email protected]> wrote:
> Hi,
>
> > I think it is cleaner to define a parameter called BAND which can
take
> > values 2.4 GHz, 5 GHz and so on. Then, the combination of BAND and
> > CHANNEL will uniquely define the operating frequency.
>
> <phymode stuff snipped>
>
> > I wasn't sure if this has already been thought about. I look forward
to
> > being educated if I am missing something.
>
> Good point. I hadn't really considered this but a/g or n cards really
> make it necessary to distinguish here, and regulatory stuff would also
> benefit from defining it that way.
>
I have to agree that the phymode lost is relevance. and band channel
couple has more meaning
In this context, what atheros turbo phy mode is? What channel, band
does it operate?
Thanks
Tomas
> johannes
>
>