[ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

Hello All,

I have been testing out ath9k in a variety of situations. I have observed it 
appears to have poorer handling in MIMO-intensive environments than the binary 
drivers under Mac OS X and Windows. I have two computers with identical radios 
(3x3:2 AR5008 Mini PCI-e) and as similar of antenna configurations as possible. 
One computer runs Windows XP + latest Atheros binary drivers and Linux 2.6.32 + 
latest compat-wireless. (I have also tested some older versions with similar 
results.) The other computer runs Mac OS X 10.6.2 which contains the latest 
Atheros binary drivers.

The APs are a mix of 5 GHz 802.11n and 802.11a, from multiple vendors and with 
varying chipsets including Atheros and Broadcom. I have tested 
greenfield/non-greenfield 802.11n modes and both 20 MHz and 40 MHz channels and 
seen similar results in all cases. In all my tests, I have a virtually 100% 
noise-free environment, non-overlapping channels, no traffic on the APs except 
the testing computers. Never has any card reported a noise value above the 
thermal/amplifier chain noise floor. There are no known 5 GHz 802.11 APs except 
for those under my control operating within 1 km.

The conclusion I am reaching is that in clean line of sight situations, the 
Linux ath9k performs as expected - almost perfectly identical to the OS X and 
Windows tests. However, as you lose line of sight and/or have increased 
multi-path, Linux / ath9k quickly falls dramatically behind the binary drivers 
in Windows and OS X. And unfortunately, in almost all real-world situations, 
multi-path is present and a major factor.

*** Situation A ***
The OS X computer picks up a remote non-LoS 5 GHz 802.11n AP without any 
problems and associates reliably. Depending on precise location, signal 
strength varies from -72 dBm to -88 dBm and typically I see MCS 3-7. Windows 
detects the AP but does not reliably associate with it. Linux does not even 
detect the AP.

*** Situation A-2 ***
Switching out the AR5008 for a high-quality AR9280 (2x2:2) does allow Linux to 
detect the remote non-LoS AP, but it still cannot associate reliably at that 
location. The AR9280's increased sensitivity seems to allow the detection of 
APs in more edge situations, but does not significantly improve non-LoS 
performance. Additional, in other limited tests, the AR9280 often yields 
significantly worse signal levels as compared to the AR5008 - sometimes 10 to 
20 dB worse.

*** Situation B ***
Testing against a very close 802.11n AP, Linux has extreme difficulty dealing 
with the strong multipath. Linux reports a signal of around -72 to -74 dBm and 
maintains a much lower bitrate with a "link quality" around 70/100. This is low 
enough that link speed is significantly reduced, with either low MCS (usually 
<4) or even dropping to 6 megabit 802.11a occasionally. By comparison, Linux 
sees an identical AP a few rooms over attains a signal strength around -50 to 
-55 dBm and a link quality of 80-90/100, and operates at full bitrate or near 
full bitrate. (The performance with the 2 rooms away AP is similar to Windows 
and OS X, one of the few non-LoS situations where Linux ath9k can match Windows 
and OS X.)

For comparison, Windows and Mac OS X both attain a 270 megabit (MCS15) 
connection and hold it fairly reliably (occasionally and only briefly dropping 
to MCS13 or MCS14) with signal in the -30s and lower -40s range. The relative 
link quality is somewhat lower than when a little further from the AP or with a 
bit less multi-path, but OS X and Windows both maintain near full bitrate and 
perform quite acceptably.

*** Situation C ***
Testing against an 802.11a AP in an adjacent room with directional antenna 
pointed away from the indoors testing location. This means all signal is 
multi-path. The Linux computer cannot reliably associate with the AP. During 
association attempts, the Linux computer reports signals in the -82 to -88 dBm 
range and link quality from 34/100 to 54/100. The Mac OS X computer reports a 
signal strength of -45 to -50 dBm, associates reliably, and attains full 
802.11a bitrate. Windows is similar to slightly behind OS X in this case.

*** Further Testing ***
I plan to create a triple-boot environment so I can compare any OS combination 
on exactly the same hardware. Absolute care will be used when rebooting as not 
to move anything. I will run a standard series of network tests under Linux and 
OS X. (It is a significantly larger headache to setup Cygwin to use the same 
tools on Windows and I will only do so if OS X versus Linux testing is 
inconclusive.) I will also have another system in monitor mode and be recording 
the raw 802.11 frames for later review.

I do not expect a significant change in behavior in my testing environment, but 
I do expect more accurate and precise data, which can hopefully help me 
identify the cause of the performance differences.

*** Discussion ***
While I realize some of my examples are rather extreme, they clearly

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Felix Fietkau]

On 2010-02-21 9:41 PM, Galen wrote:
> Hello All,
> 
> I have been testing out ath9k in a variety of situations. I have
> observed it appears to have poorer handling in MIMO-intensive
> environments than the binary drivers under Mac OS X and Windows. I
> have two computers with identical radios (3x3:2 AR5008 Mini PCI-e)
> and as similar of antenna configurations as possible. One computer
> runs Windows XP + latest Atheros binary drivers and Linux 2.6.32 +
> latest compat-wireless. (I have also tested some older versions with
> similar results.) The other computer runs Mac OS X 10.6.2 which
> contains the latest Atheros binary drivers.
> 
> *** Further Testing *** I plan to create a triple-boot environment so
> I can compare any OS combination on exactly the same hardware.
> Absolute care will be used when rebooting as not to move anything. I
> will run a standard series of network tests under Linux and OS X. (It
> is a significantly larger headache to setup Cygwin to use the same
> tools on Windows and I will only do so if OS X versus Linux testing
> is inconclusive.) I will also have another system in monitor mode and
> be recording the raw 802.11 frames for later review.
> 
> I do not expect a significant change in behavior in my testing
> environment, but I do expect more accurate and precise data, which
> can hopefully help me identify the cause of the performance
> differences.
> 
> *** Discussion *** While I realize some of my examples are rather
> extreme, they clearly demonstrate the huge disparity between ath9k
> and proprietary drivers. I suspect that ath9k may have inferior MIMO
> support code (MRC, beamforming, etc.) as compared to the proprietary
> drivers. I believe that STBC is still not supported yet either.
All of the currently available common Atheros hardware such as AR9280
and earlier chip generations do not have MRC, Beamforming and similar
advanced features.
Except for STBC, ath9k seems to have pretty much the same hardware
features as Atheros' other drivers. There may be some workarounds for
various hw issues missing, I have not extensively reviewed that yet.

While I haven't done any tests with it yet, I believe STBC could
potentially make a difference in strong multipath environments,
especially when dealing with lower signal strength.
The signal strength issues might also be related to ANI, you should
probably disable that in ath9k to make sure that it's not screwing up
your test results.

> Can anybody comment on this issue? Have you experienced it yourself?
While I haven't done any extensive testing in that area, nor compared it
against proprietary APs directly, your description of ath9k issues
sounds somewhat similar to what I'm seeing with AR9280 hardware in my tests.

> Does anybody have ideas on how this might be improved? I have been
> considering ath9k for an embedded installation, but these multi-path
> performance differences are pretty disturbing. Atheros has a
> proprietary driver available with source for a very hefty license
> fee, but I'd rather put energies into ath9k - the kind of licensing
> fees they are working with can pay for a lot of developer time.
I'm currently working on a new rate control algorithm for 11n, and I
also intend to add STBC support to ath9k soon (it's only a few flags
missing, nothing major). Maybe I should do STBC first, as it should be
fairly straightforward.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 22, 2010, at 6:29 AM, Felix Fietkau wrote:

>> *** Discussion *** While I realize some of my examples are rather
>> extreme, they clearly demonstrate the huge disparity between ath9k
>> and proprietary drivers. I suspect that ath9k may have inferior MIMO
>> support code (MRC, beamforming, etc.) as compared to the proprietary
>> drivers. I believe that STBC is still not supported yet either.
> All of the currently available common Atheros hardware such as AR9280
> and earlier chip generations do not have MRC, Beamforming and similar
> advanced features.

As Atheros does not release technical specifications without NDA, I do not have 
a clear picture of what is and is not supported by a particular chipset. 
Reviewing the ath9k source code is a very intensive process and only provides a 
partial picture. Some features might be implemented 100% in hardware, making 
them difficult to discern from ath9k source alone. 

> Except for STBC, ath9k seems to have pretty much the same hardware
> features as Atheros' other drivers. There may be some workarounds for
> various hw issues missing, I have not extensively reviewed that yet.

I would be interested in knowing more about these. LDPC? Others? There appear 
good software implementations of LDPC out there:
http://planete-bcast.inrialpes.fr/article.php3?id_article=7

> While I haven't done any tests with it yet, I believe STBC could
> potentially make a difference in strong multipath environments,
> especially when dealing with lower signal strength.

Yes, I would tend to agree this could help significantly. 

Are there details about what you are implementing? Are you implementing 
encoding or decoding or both? Are you using an orthogonal or quasi-orthagonal 
code? Have you considered a hybrid system using a quasi-orthagonal code at low 
SNR and orthogonal at higher SNR? 

> The signal strength issues might also be related to ANI, you should
> probably disable that in ath9k to make sure that it's not screwing up
> your test results.

If I am not mistaken, ANI seems unlikely to have a negative impact on 
performance. Do you believe it could be aversely affecting performance, or do 
you believe that it is simply causing the signal numbers to be mis-reported?

>> Can anybody comment on this issue? Have you experienced it yourself?
> While I haven't done any extensive testing in that area, nor compared it
> against proprietary APs directly, your description of ath9k issues
> sounds somewhat similar to what I'm seeing with AR9280 hardware in my tests.

I have a good testing environment and strong interests in seeing better 
performance, so let me know if there is anything I can test for you. I have 
AR5008, AR9280, AR9281 all on-hand, including radio modules from multiple 
vendors for each of these chips. I will probably be equipped to test AR9220 and 
AR9160 soon. I have a wide variety antennas from essentially zero gain to 30 dB 
and a mix of indoor and outdoor line of sight testing possible. All testing 
machines are setup with the latest Debian testing, so they always have the 
latest kernel, etc.

>> Does anybody have ideas on how this might be improved? I have been
>> considering ath9k for an embedded installation, but these multi-path
>> performance differences are pretty disturbing. Atheros has a
>> proprietary driver available with source for a very hefty license 
>> fee, but I'd rather put energies into ath9k - the kind of licensing
>> fees they are working with can pay for a lot of developer time.
> I'm currently working on a new rate control algorithm for 11n, and I
> also intend to add STBC support to ath9k soon (it's only a few flags
> missing, nothing major). Maybe I should do STBC first, as it should be
> fairly straightforward.

I tend to think the STBC is probably a lot more foundational than rate control.

That said, I am curious, what changes to the rate control are you planning / 
working on?

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Felix Fietkau]

On 2010-02-22 8:43 PM, Galen wrote:
> On Feb 22, 2010, at 6:29 AM, Felix Fietkau wrote:
> 
>>> *** Discussion *** While I realize some of my examples are rather
>>> extreme, they clearly demonstrate the huge disparity between ath9k
>>> and proprietary drivers. I suspect that ath9k may have inferior MIMO
>>> support code (MRC, beamforming, etc.) as compared to the proprietary
>>> drivers. I believe that STBC is still not supported yet either.
>> All of the currently available common Atheros hardware such as AR9280
>> and earlier chip generations do not have MRC, Beamforming and similar
>> advanced features.
> 
> As Atheros does not release technical specifications without NDA, I
> do not have a clear picture of what is and is not supported by a particular
> chipset. Reviewing the ath9k source code is a very intensive process and
> only provides a partial picture. Some features might be implemented 100%
> in hardware, making them difficult to discern from ath9k source alone.
Since I do commercial work for some companies using Atheros based stuff,
I know a few things about the other codebases ;)

>> Except for STBC, ath9k seems to have pretty much the same hardware
>> features as Atheros' other drivers. There may be some workarounds for
>> various hw issues missing, I have not extensively reviewed that yet.
> I would be interested in knowing more about these. LDPC? Others?
> There appear good software implementations of LDPC out there:
> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
I'm pretty sure the current hardware also doesn't do LDPC yet.

>> While I haven't done any tests with it yet, I believe STBC could
>> potentially make a difference in strong multipath environments,
>> especially when dealing with lower signal strength.
> 
> Yes, I would tend to agree this could help significantly. 
> 
> Are there details about what you are implementing? Are you
> implementing encoding or decoding or both? Are you using an orthogonal
> or quasi-orthagonal code? Have you considered a hybrid system using a
> quasi-orthagonal code at low SNR and orthogonal at higher SNR? 
I think the hardware can only do 2:1 STBC

>> The signal strength issues might also be related to ANI, you should
>> probably disable that in ath9k to make sure that it's not screwing up
>> your test results.
> 
> If I am not mistaken, ANI seems unlikely to have a negative impact
> on performance. Do you believe it could be aversely affecting performance,
> or do you believe that it is simply causing the signal numbers to be
> mis-reported?
ANI messes with the AGC parameters, OFDM or CCK self-correlation during
reception, spur mitigation, and a few other things. Atheros has
published a patent on this a while back. Look it up and read it if
you're curious about the details.
Short answer: I've seen it mess with the reported signal strength in
their legacy chips, and I believe there's a good chance it still holds
true for the 11n variants.

>>> Can anybody comment on this issue? Have you experienced it yourself?
>> While I haven't done any extensive testing in that area, nor compared it
>> against proprietary APs directly, your description of ath9k issues
>> sounds somewhat similar to what I'm seeing with AR9280 hardware in my tests.
> 
> I have a good testing environment and strong interests in seeing
> better performance, so let me know if there is anything I can test for
> you. I have AR5008, AR9280, AR9281 all on-hand, including radio modules
> from multiple vendors for each of these chips. I will probably be
> equipped to test AR9220 and AR9160 soon. I have a wide variety antennas
> from essentially zero gain to 30 dB and a mix of indoor and outdoor line
> of sight testing possible. All testing machines are setup with the
> latest Debian testing, so they always have the latest kernel, etc.
You should use compat-wireless based on the wireless-testing sources, it
contains a lot of stuff that hasn't made it into stable kernels yet.
This is also what I use for the mac80211+drivers packages in OpenWrt.

>>> Does anybody have ideas on how this might be improved? I have been
>>> considering ath9k for an embedded installation, but these multi-path
>>> performance differences are pretty disturbing. Atheros has a
>>> proprietary driver available with source for a very hefty license 
>>> fee, but I'd rather put energies into ath9k - the kind of licensing
>>> fees they are working with can pay for a lot of developer time.
>> I'm currently working on a new rate control algorithm for 11n, and I
>> also intend to add STBC support to ath9k soon (it's only a few flags
>> missing, nothing major). Maybe I should do STBC first, as it should be
>> fairly straightforward.
> 
> I tend to think the STBC is probably a lot more foundational than rate 
> control.
> 
> That said, I am curious, what changes to the rate control are you planning / 
> working on?
I started adapting the minstrel algorithm for 11n (it's a rewrite,
actually), but found out by testing 

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:

> On 2010-02-22 8:43 PM, Galen wrote:
>> On Feb 22, 2010, at 6:29 AM, Felix Fietkau wrote:
>>> Except for STBC, ath9k seems to have pretty much the same hardware
>>> features as Atheros' other drivers. There may be some workarounds for
>>> various hw issues missing, I have not extensively reviewed that yet.
>> I would be interested in knowing more about these. LDPC? Others?
>> There appear good software implementations of LDPC out there:
>> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
> I'm pretty sure the current hardware also doesn't do LDPC yet.

Ah - I misunderstood. I thought you were thinking of implementing previously 
unavailable features in software. I wasn't sure how far the "soft MAC" idea 
went :)

That said, I've reviewed what the chipsets currently available claim to support.

What is the status of 802.11h in AP mode? The ath9k page at linuxwireless.org 
says it's supported, but I think that is only for clients, not APs. (Clients 
simply offload radar detection to the AP, and follow the AP's directions if 
radar is detected.)

Similar question about 802.11d - listed as supported, but is this only client 
mode?

What about 802.11e? Client mode? AP mode?

And while of least importance to most people, 802.11j?

>>> While I haven't done any tests with it yet, I believe STBC could
>>> potentially make a difference in strong multipath environments,
>>> especially when dealing with lower signal strength.
>> 
>> Yes, I would tend to agree this could help significantly. 
>> 
>> Are there details about what you are implementing? Are you
>> implementing encoding or decoding or both? Are you using an orthogonal
>> or quasi-orthagonal code? Have you considered a hybrid system using a
>> quasi-orthagonal code at low SNR and orthogonal at higher SNR? 
> I think the hardware can only do 2:1 STBC

Ah - once again, you're enabling the hardware function, not implementing it in 
software.

>> If I am not mistaken, ANI seems unlikely to have a negative impact
>> on performance. Do you believe it could be aversely affecting performance,
>> or do you believe that it is simply causing the signal numbers to be
>> mis-reported?
> ANI messes with the AGC parameters, OFDM or CCK self-correlation during
> reception, spur mitigation, and a few other things. Atheros has
> published a patent on this a while back. Look it up and read it if
> you're curious about the details.
> Short answer: I've seen it mess with the reported signal strength in
> their legacy chips, and I believe there's a good chance it still holds
> true for the 11n variants.

I will do some tests soon here. However, if you have STBC code coming soon, I'd 
love to give that a try too and really be able to comprehensively evaluate 
things.

>> I have a good testing environment and strong interests in seeing
>> better performance, so let me know if there is anything I can test for
>> you. I have AR5008, AR9280, AR9281 all on-hand, including radio modules
>> from multiple vendors for each of these chips. I will probably be
>> equipped to test AR9220 and AR9160 soon. I have a wide variety antennas
>> from essentially zero gain to 30 dB and a mix of indoor and outdoor line
>> of sight testing possible. All testing machines are setup with the
>> latest Debian testing, so they always have the latest kernel, etc.
> You should use compat-wireless based on the wireless-testing sources, it
> contains a lot of stuff that hasn't made it into stable kernels yet.
> This is also what I use for the mac80211+drivers packages in OpenWrt.

I am sorry, I was not clear. I always build a fresh compat-wireless.

>> That said, I am curious, what changes to the rate control are you planning / 
>> working on?
> I started adapting the minstrel algorithm for 11n (it's a rewrite,
> actually), but found out by testing that without modifications the
> general approach isn't really suitable for 11n yet.
> 
> So I'm playing with a couple of ideas for a new approach, which I can
> easily fit into the code that I have already written. I don't really
> have a name for that stuff yet (it deviates quite a bit from the
> minstrel approach), but it will be posted as an RFC patch to the
> linux-wireless list as soon as it's somewhat usable.

I'll be interested to see what you are working on here.

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

This is an addendum to my earlier reply.

On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
>>> Except for STBC, ath9k seems to have pretty much the same hardware
>>> features as Atheros' other drivers. There may be some workarounds for
>>> various hw issues missing, I have not extensively reviewed that yet.
>> I would be interested in knowing more about these. LDPC? Others?
>> There appear good software implementations of LDPC out there:
>> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
> I'm pretty sure the current hardware also doesn't do LDPC yet.

I have looked over data presented on the Atheros website and as best as I can 
tell, the AR5008 (and other newer chipsets, I assume) support:

- STBC (space-time block coding) for TX and RX
- MRC (maximal ratio combining) via zero forcing algorithm 
- TxBF (transmit beam forming) 

>From what you're saying, my understanding is that MRC and and TxBF are both 
>functioning with ath9k, with STBC being the primary remaining feature. Is this 
>correct?
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Felix Fietkau]

On 2010-02-24 8:22 PM, Galen wrote:
> This is an addendum to my earlier reply.
> 
> On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
 Except for STBC, ath9k seems to have pretty much the same hardware
 features as Atheros' other drivers. There may be some workarounds for
 various hw issues missing, I have not extensively reviewed that yet.
>>> I would be interested in knowing more about these. LDPC? Others?
>>> There appear good software implementations of LDPC out there:
>>> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
>> I'm pretty sure the current hardware also doesn't do LDPC yet.
> 
> I have looked over data presented on the Atheros website and as best as I can 
> tell, the AR5008 (and other newer chipsets, I assume) support:
> 
> - STBC (space-time block coding) for TX and RX
> - MRC (maximal ratio combining) via zero forcing algorithm 
> - TxBF (transmit beam forming) 
> 
> From what you're saying, my understanding is that MRC and and TxBF
> are both functioning with ath9k, with STBC being the primary
> remaining feature. Is this correct?
TxBF isn't supported by the currently available hardware, so ath9k
doesn't make use of it either. I don't know about MRC, but I don't see a
difference between ath9k and other Atheros drivers in that area.
So yes, of those options, only STBC is missing.

- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote:

> On 2010-02-24 8:22 PM, Galen wrote:
>> This is an addendum to my earlier reply.
>> 
>> On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
> Except for STBC, ath9k seems to have pretty much the same hardware
> features as Atheros' other drivers. There may be some workarounds for
> various hw issues missing, I have not extensively reviewed that yet.
 I would be interested in knowing more about these. LDPC? Others?
 There appear good software implementations of LDPC out there:
 http://planete-bcast.inrialpes.fr/article.php3?id_article=7
>>> I'm pretty sure the current hardware also doesn't do LDPC yet.
>> 
>> I have looked over data presented on the Atheros website and as best as I 
>> can tell, the AR5008 (and other newer chipsets, I assume) support:
>> 
>> - STBC (space-time block coding) for TX and RX
>> - MRC (maximal ratio combining) via zero forcing algorithm 
>> - TxBF (transmit beam forming) 
>> 
>> From what you're saying, my understanding is that MRC and and TxBF
>> are both functioning with ath9k, with STBC being the primary
>> remaining feature. Is this correct?
> TxBF isn't supported by the currently available hardware, so ath9k
> doesn't make use of it either. I don't know about MRC, but I don't see a
> difference between ath9k and other Atheros drivers in that area.
> So yes, of those options, only STBC is missing.

Atheros' data is not very clear in all cases. However, their statements lead 
one to believe that transmit beamforming is supported, as is MRC. 

It is possible that MRC is 100% hardware based (DSP-level) and "invisible" to 
the hardware. Is that what you mean when you say, "I don't know about MRC" ?

As for transmit beamforming, here's a great example of their clear-as-mud 
information:
http://www.atheros.com/news/xspan.html

Note how they say "The new 802.11n draft specification defines an array of 
technical elements that Atheros is uniquely qualified to deliver" and list many 
features which I know the hardware supports - then list two I'm not sure about, 
MRC and TxBF. 

They clearly state that MRC and TxBF were implemented in chipsets dating back 
to 2004. However, are they in their shipping 802.11n chipsets? It's not clear. 
But why would they drop important features like that from a next-generation 
chipset? They also have this new brand for their MIMO technology - "Signal 
Sustain" technology - which nicely obfuscates what's actually happening.

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[rootkit85]

On Wed, Feb 24, 2010 at 8:41 PM, Galen  wrote:
>
> On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote:
>
>> On 2010-02-24 8:22 PM, Galen wrote:
>>> This is an addendum to my earlier reply.
>>>
>>> On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
>> Except for STBC, ath9k seems to have pretty much the same hardware
>> features as Atheros' other drivers. There may be some workarounds for
>> various hw issues missing, I have not extensively reviewed that yet.
> I would be interested in knowing more about these. LDPC? Others?
> There appear good software implementations of LDPC out there:
> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
 I'm pretty sure the current hardware also doesn't do LDPC yet.
>>>
>>> I have looked over data presented on the Atheros website and as best as I 
>>> can tell, the AR5008 (and other newer chipsets, I assume) support:
>>>
>>> - STBC (space-time block coding) for TX and RX
>>> - MRC (maximal ratio combining) via zero forcing algorithm
>>> - TxBF (transmit beam forming)
>>>
>>> From what you're saying, my understanding is that MRC and and TxBF
>>> are both functioning with ath9k, with STBC being the primary
>>> remaining feature. Is this correct?
>> TxBF isn't supported by the currently available hardware, so ath9k
>> doesn't make use of it either. I don't know about MRC, but I don't see a
>> difference between ath9k and other Atheros drivers in that area.
>> So yes, of those options, only STBC is missing.
>
> Atheros' data is not very clear in all cases. However, their statements lead 
> one to believe that transmit beamforming is supported, as is MRC.
>
> It is possible that MRC is 100% hardware based (DSP-level) and "invisible" to 
> the hardware. Is that what you mean when you say, "I don't know about MRC" ?
>
> As for transmit beamforming, here's a great example of their clear-as-mud 
> information:
> http://www.atheros.com/news/xspan.html
>
> Note how they say "The new 802.11n draft specification defines an array of 
> technical elements that Atheros is uniquely qualified to deliver" and list 
> many features which I know the hardware supports - then list two I'm not sure 
> about, MRC and TxBF.
>
> They clearly state that MRC and TxBF were implemented in chipsets dating back 
> to 2004. However, are they in their shipping 802.11n chipsets? It's not 
> clear. But why would they drop important features like that from a 
> next-generation chipset? They also have this new brand for their MIMO 
> technology - "Signal Sustain" technology - which nicely obfuscates what's 
> actually happening.
>
> -Galen
> ___
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

Now they also have SST3: http://www.atheros.com/news/AR9300.html

"Leveraging the Rich Array of 11n Features to Enhance Rate-over-Range
Atheros’ new implementation of 11n leverages a variety of range
enhancement options to ensure that the high throughput levels achieved
with the 3x3 MIMO configuration are maintained across the entire WLAN
link.

Low Density Parity Check (LDPC) guards against packet loss at every
point on the link.
Maximum Likelihood Demodulation (MLD) optimizes MIMO demodulation to
boost signal strength at close range.
Transmit Beamforming (TxBF) focuses transmit signals to the receiver
to enhance the link rate at mid-range on the link continuum.
Maximal Ratio Combining (MRC) enables the receiver to optimally
combine the MIMO signal paths, aligning time and phase of the signal
receive to extend link reliability at longer range."

It seems they don't claim such feature set in AR9200:

http://www.atheros.com/news/AR9280_AR9281.html
http://www.atheros.com/pt/AR9285.htm
http://www.atheros.com/news/AR9220_AR9223.html

so I'm a bit confused about this
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

On Wed, Feb 24, 2010 at 11:41:46AM -0800, Galen wrote:
> 
> On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote:
> 
> > On 2010-02-24 8:22 PM, Galen wrote:
> >> This is an addendum to my earlier reply.
> >> 
> >> On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
> > Except for STBC, ath9k seems to have pretty much the same hardware
> > features as Atheros' other drivers. There may be some workarounds for
> > various hw issues missing, I have not extensively reviewed that yet.
>  I would be interested in knowing more about these. LDPC? Others?
>  There appear good software implementations of LDPC out there:
>  http://planete-bcast.inrialpes.fr/article.php3?id_article=7
> >>> I'm pretty sure the current hardware also doesn't do LDPC yet.
> >> 
> >> I have looked over data presented on the Atheros website and as best as I 
> >> can tell, the AR5008 (and other newer chipsets, I assume) support:
> >> 
> >> - STBC (space-time block coding) for TX and RX
> >> - MRC (maximal ratio combining) via zero forcing algorithm 
> >> - TxBF (transmit beam forming) 
> >> 
> >> From what you're saying, my understanding is that MRC and and TxBF
> >> are both functioning with ath9k, with STBC being the primary
> >> remaining feature. Is this correct?
> > TxBF isn't supported by the currently available hardware, so ath9k
> > doesn't make use of it either. I don't know about MRC, but I don't see a
> > difference between ath9k and other Atheros drivers in that area.
> > So yes, of those options, only STBC is missing.
> 
> Atheros' data is not very clear in all cases. However, their statements
> lead one to believe that transmit beamforming is supported, as is MRC. 

MRC is supported on all 11n chipsets, but not for cck rates.
TX beamforming is only supported on the shiny new AR93xx
chipsets. TX beamforming seems to have been supported on
some old legacy chipset but there is no code to support it
and I wouldn't bother trying.

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 24, 2010, at 4:33 PM, rootki...@yahoo.it wrote:

> On Wed, Feb 24, 2010 at 8:41 PM, Galen  wrote:
>> 
>> On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote:
>> 
>>> On 2010-02-24 8:22 PM, Galen wrote:
 This is an addendum to my earlier reply.
 
 On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
>>> Except for STBC, ath9k seems to have pretty much the same hardware
>>> features as Atheros' other drivers. There may be some workarounds for
>>> various hw issues missing, I have not extensively reviewed that yet.
>> I would be interested in knowing more about these. LDPC? Others?
>> There appear good software implementations of LDPC out there:
>> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
> I'm pretty sure the current hardware also doesn't do LDPC yet.
 
 I have looked over data presented on the Atheros website and as best as I 
 can tell, the AR5008 (and other newer chipsets, I assume) support:
 
 - STBC (space-time block coding) for TX and RX
 - MRC (maximal ratio combining) via zero forcing algorithm
 - TxBF (transmit beam forming)
 
 From what you're saying, my understanding is that MRC and and TxBF
 are both functioning with ath9k, with STBC being the primary
 remaining feature. Is this correct?
>>> TxBF isn't supported by the currently available hardware, so ath9k
>>> doesn't make use of it either. I don't know about MRC, but I don't see a
>>> difference between ath9k and other Atheros drivers in that area.
>>> So yes, of those options, only STBC is missing.
>> 
>> Atheros' data is not very clear in all cases. However, their statements lead 
>> one to believe that transmit beamforming is supported, as is MRC.
>> 
>> It is possible that MRC is 100% hardware based (DSP-level) and "invisible" 
>> to the hardware. Is that what you mean when you say, "I don't know about 
>> MRC" ?
>> 
>> As for transmit beamforming, here's a great example of their clear-as-mud 
>> information:
>> http://www.atheros.com/news/xspan.html
>> 
>> Note how they say "The new 802.11n draft specification defines an array of 
>> technical elements that Atheros is uniquely qualified to deliver" and list 
>> many features which I know the hardware supports - then list two I'm not 
>> sure about, MRC and TxBF.
>> 
>> They clearly state that MRC and TxBF were implemented in chipsets dating 
>> back to 2004. However, are they in their shipping 802.11n chipsets? It's not 
>> clear. But why would they drop important features like that from a 
>> next-generation chipset? They also have this new brand for their MIMO 
>> technology - "Signal Sustain" technology - which nicely obfuscates what's 
>> actually happening.
>> 
>> -Galen
>> 
> 
> Now they also have SST3: http://www.atheros.com/news/AR9300.html
> 
> "Leveraging the Rich Array of 11n Features to Enhance Rate-over-Range
> Atheros’ new implementation of 11n leverages a variety of range
> enhancement options to ensure that the high throughput levels achieved
> with the 3x3 MIMO configuration are maintained across the entire WLAN
> link.
> 
> Low Density Parity Check (LDPC) guards against packet loss at every
> point on the link.
> Maximum Likelihood Demodulation (MLD) optimizes MIMO demodulation to
> boost signal strength at close range.
> Transmit Beamforming (TxBF) focuses transmit signals to the receiver
> to enhance the link rate at mid-range on the link continuum.
> Maximal Ratio Combining (MRC) enables the receiver to optimally
> combine the MIMO signal paths, aligning time and phase of the signal
> receive to extend link reliability at longer range."
> 
> It seems they don't claim such feature set in AR9200:
> 
> http://www.atheros.com/news/AR9280_AR9281.html
> http://www.atheros.com/pt/AR9285.htm
> http://www.atheros.com/news/AR9220_AR9223.html
> 
> so I'm a bit confused about this


I am aware of the AR9300 features / SST3.

The AR9100 and AR9200 also contains SST. It is not always mentioned, but it is 
present in many different specifications I have seen for the AR9100 and AR9200 
family of chipsets. I think there is some discussion still as to what SST is, 
however...

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 24, 2010, at 4:39 PM, Luis R. Rodriguez wrote:

> On Wed, Feb 24, 2010 at 11:41:46AM -0800, Galen wrote:
>> 
>> On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote:
>> 
>>> On 2010-02-24 8:22 PM, Galen wrote:
 This is an addendum to my earlier reply.
 
 On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
>>> Except for STBC, ath9k seems to have pretty much the same hardware
>>> features as Atheros' other drivers. There may be some workarounds for
>>> various hw issues missing, I have not extensively reviewed that yet.
>> I would be interested in knowing more about these. LDPC? Others?
>> There appear good software implementations of LDPC out there:
>> http://planete-bcast.inrialpes.fr/article.php3?id_article=7
> I'm pretty sure the current hardware also doesn't do LDPC yet.
 
 I have looked over data presented on the Atheros website and as best as I 
 can tell, the AR5008 (and other newer chipsets, I assume) support:
 
 - STBC (space-time block coding) for TX and RX
 - MRC (maximal ratio combining) via zero forcing algorithm 
 - TxBF (transmit beam forming) 
 
 From what you're saying, my understanding is that MRC and and TxBF
 are both functioning with ath9k, with STBC being the primary
 remaining feature. Is this correct?
>>> TxBF isn't supported by the currently available hardware, so ath9k
>>> doesn't make use of it either. I don't know about MRC, but I don't see a
>>> difference between ath9k and other Atheros drivers in that area.
>>> So yes, of those options, only STBC is missing.
>> 
>> Atheros' data is not very clear in all cases. However, their statements
>> lead one to believe that transmit beamforming is supported, as is MRC. 
> 
> MRC is supported on all 11n chipsets, but not for cck rates.
> TX beamforming is only supported on the shiny new AR93xx
> chipsets. TX beamforming seems to have been supported on
> some old legacy chipset but there is no code to support it
> and I wouldn't bother trying.
> 
>  Luis


Luis - can you comment on the MRC implementation? Is this entirely invisible to 
ath9k, or is this implemented / supported in software?

And to be clear, you think the 802.11n chipsets before the AR9300 *do not* 
include TxBF at all? Not that it simply isn't supported by the drivers?

It does make some sense why they might drop TxBF when 802.11n arrived. Spatial 
multiplexing and TxBF are mutually exclusive when spatial streams = number of 
TX chains. Gains from TxBF are claimed to be anywhere from 3 to 9 dB, but in 
many mid-range cases, one would obtain better throughput by accepting two 
spatial streams at lower signal and throughput versus one at higher throughput.

For example, on the SR71-E @ 5 GHz w/20 MHz channels, the MCS7 sensitivity is 
-75 dBm, with a throughput around 65 megabits, and the MCS13 sensitivity is -85 
dBm, with a throughput of 105 megabits. While these are assuming optimal 
situations, a 10 dB difference is still significant. 

Additionally, I think the benefits of TxBF are significantly reduced when STBC 
and MRC is employed.

I think the delay to re-introducing TxBF is due to both the smaller benefit and 
the greater complexity. Implementing it with three antennas requires logic when 
to adapt the number of spatial streams down to better use TxBF, and increased 
DSP to analyze how to use 3 spatial streams to beamform. I also suspect that 
beamforming two spatial streams using one additional radio is probably quite 
complex, if not entirely lacking viability.

I could be wrong on any of these points - if so, please correct me.

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

On Thu, Feb 25, 2010 at 08:03:57PM -0800, Galen wrote:
> I am aware of the AR9300 features / SST3.
> 
> The AR9100 and AR9200 also contains SST

Oh? I thought SST thing was the marketing name for our
full solution of 3 stream for 802.11n.

> It is not always mentioned, but it is present in many different
> specifications I have seen for the AR9100 and AR9200 family of
> chipsets. I think there is some discussion still as to what SST is, however...

Again, I thought it was just our full 3 stream stuff.

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

On Thu, Feb 25, 2010 at 09:37:12PM -0800, Galen wrote:
> On Feb 24, 2010, at 4:39 PM, Luis R. Rodriguez wrote:
> > MRC is supported on all 11n chipsets, but not for cck rates.
> > TX beamforming is only supported on the shiny new AR93xx
> > chipsets. TX beamforming seems to have been supported on
> > some old legacy chipset but there is no code to support it
> > and I wouldn't bother trying.
> > 
> >  Luis
> 
> 
> Luis - can you comment on the MRC implementation? Is this entirely
> invisible to ath9k, or is this implemented / supported in software?

No, frankly this is the first time I read about MRC.
I just poked a few guys here about MRC and got the clarification
above.

> And to be clear, you think the 802.11n chipsets before the
> AR9300 *do not* include TxBF at all? Not that it simply isn't
> supported by the drivers?

Only a legacy (802.11g) end of life'd device had some form
of Tx beamforming, but that's not even supported and its easier
to just assume no chipset supports it other than the shiny
new AR93xx family.

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

On Fri, Feb 26, 2010 at 09:13:28AM -0800, Daniel Halperin wrote:
> p.p.s. If you do want to learn more about the RF side of things and are 
> willing to tackle an explanation written for computer scientists without a 
> strong EE / RF signal processing background, you can check out our tutorial 
> called "802.11 with Multiple Antennas for Dummies." It's available from ACM 
> here (we kept the copyright, so it should be free) 
>  or off my website 
>  direct PDF link: 
>  .

Neat I've put a reference to this on this page:

http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n

Thanks for sharing. BTW if any of you guys can add MRC/Tx Beamforing to that 
wiki it'd be nice :)

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Daniel Halperin]

On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote:

>> Luis - can you comment on the MRC implementation? Is this entirely
>> invisible to ath9k, or is this implemented / supported in software?
> 
> No, frankly this is the first time I read about MRC.
> I just poked a few guys here about MRC and got the clarification
> above.

I'm confused about your goals, Galen? What is it you're trying to learn about 
the chips? Do you want to understand the RF-level wireless processing, or don't 
you? The answers are much easier to intuit if one understands the underlying 
processing, and I don't see how your questions can return valuable information 
if one does not :).

MRC is a receiver-side technique that is entirely performed at the RF 
processing layer (likely in the DSP) and as such should be opaque to the 
driver-level software. It involves making the copies of signals received by the 
different antennas coherent and adding them before doing the normal RF 
processing that turns the electromagnetic signals into bits. This is simply not 
the purpose of the software available on the host side, even in a software 
HAL/MAC; this functionality is likely to be in DSP ASICs on the chips 
themselves.

The only way I envision software having anything to do with MRC would be 
(maybe) some software-side control of what relative power level thresholds to 
use to decide when MRC is worth it. If antenna A has a signal that is 20 dB 
(100x) stronger than antenna B, it's likely not worth combining A and B's 
signals (and might take extra computation/power) and instead better to just use 
A. Maybe the 20 dB is configurable in ath5k/9k as it is in iwlwifi. Other than 
that, I'd expect there to be pretty much no software mention of MRC.

Dan

p.s. TxBF is still helpful with multiple spatial streams. You can combine TxBF 
with fewer streams than (or equal) antennas, and there are (often sizable) 
gains.

p.p.s. If you do want to learn more about the RF side of things and are willing 
to tackle an explanation written for computer scientists without a strong EE / 
RF signal processing background, you can check out our tutorial called "802.11 
with Multiple Antennas for Dummies." It's available from ACM here (we kept the 
copyright, so it should be free) 
 or off my website 
 direct PDF link: 
 .
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote:

> On Thu, Feb 25, 2010 at 09:37:12PM -0800, Galen wrote:
>> On Feb 24, 2010, at 4:39 PM, Luis R. Rodriguez wrote:
>>> MRC is supported on all 11n chipsets, but not for cck rates.
>>> TX beamforming is only supported on the shiny new AR93xx
>>> chipsets. TX beamforming seems to have been supported on
>>> some old legacy chipset but there is no code to support it
>>> and I wouldn't bother trying.
>>> 
>>> Luis
>> 
>> 
>> Luis - can you comment on the MRC implementation? Is this entirely
>> invisible to ath9k, or is this implemented / supported in software?
> 
> No, frankly this is the first time I read about MRC.
> I just poked a few guys here about MRC and got the clarification
> above.

Right - so the MRC functionality is in the chip's DSP and entirely invisible to 
the software? Yes? Just being 100% clear here...

>> And to be clear, you think the 802.11n chipsets before the
>> AR9300 *do not* include TxBF at all? Not that it simply isn't
>> supported by the drivers?
> 
> Only a legacy (802.11g) end of life'd device had some form
> of Tx beamforming, but that's not even supported and its easier
> to just assume no chipset supports it other than the shiny
> new AR93xx family.

Right - and as discussed, TxBF has less benefit than with 802.11n. Since then, 
I have looked at some Matlab simulations here and seeing that 2 antenna MRC can 
slightly outperform 2 antenna TxBF. 
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 26, 2010, at 9:13 AM, Daniel Halperin wrote:

> On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote:
> 
>>> Luis - can you comment on the MRC implementation? Is this entirely
>>> invisible to ath9k, or is this implemented / supported in software?
>> 
>> No, frankly this is the first time I read about MRC.
>> I just poked a few guys here about MRC and got the clarification
>> above.
> 
> I'm confused about your goals, Galen? What is it you're trying to learn about 
> the chips? Do you want to understand the RF-level wireless processing, or 
> don't you? The answers are much easier to intuit if one understands the 
> underlying processing, and I don't see how your questions can return valuable 
> information if one does not :).

I understand a significant amount about the DSP and RF processing, but I'm no 
chip designer, nor have I any plans to be one.

> MRC is a receiver-side technique that is entirely performed at the RF 
> processing layer (likely in the DSP) and as such should be opaque to the 
> driver-level software. It involves making the copies of signals received by 
> the different antennas coherent and adding them before doing the normal RF 
> processing that turns the electromagnetic signals into bits. This is simply 
> not the purpose of the software available on the host side, even in a 
> software HAL/MAC; this functionality is likely to be in DSP ASICs on the 
> chips themselves.

I understand most of this function is probably in the DSP - but nothing 
documented to date had told me whether MRC was actually present. It looks like 
it's entirely invisible to software which is fine. 

> The only way I envision software having anything to do with MRC would be 
> (maybe) some software-side control of what relative power level thresholds to 
> use to decide when MRC is worth it. If antenna A has a signal that is 20 dB 
> (100x) stronger than antenna B, it's likely not worth combining A and B's 
> signals (and might take extra computation/power) and instead better to just 
> use A. Maybe the 20 dB is configurable in ath5k/9k as it is in iwlwifi. Other 
> than that, I'd expect there to be pretty much no software mention of MRC.
> 
> Dan
> 
> p.s. TxBF is still helpful with multiple spatial streams. You can combine 
> TxBF with fewer streams than (or equal) antennas, and there are (often 
> sizable) gains.

Yes - I was looking around at this with Matlab simulations. But it seems like 
in a lot of cases with 2x2 configurations, by the time you have MRC and STBC 
involved, you tend to primarily extend your range more than increase your 
throughput in excellent to moderate SNR situations.

> p.p.s. If you do want to learn more about the RF side of things and are 
> willing to tackle an explanation written for computer scientists without a 
> strong EE / RF signal processing background, you can check out our tutorial 
> called "802.11 with Multiple Antennas for Dummies." It's available from ACM 
> here (we kept the copyright, so it should be free) 
>  or off my website 
>  direct PDF link: 
>  .
> ___
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

On Fri, Feb 26, 2010 at 12:45:02PM -0800, Galen wrote:
> 
> On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote:
> 
> > On Thu, Feb 25, 2010 at 09:37:12PM -0800, Galen wrote:
> >> On Feb 24, 2010, at 4:39 PM, Luis R. Rodriguez wrote:
> >>> MRC is supported on all 11n chipsets, but not for cck rates.
> >>> TX beamforming is only supported on the shiny new AR93xx
> >>> chipsets. TX beamforming seems to have been supported on
> >>> some old legacy chipset but there is no code to support it
> >>> and I wouldn't bother trying.
> >>> 
> >>> Luis
> >> 
> >> 
> >> Luis - can you comment on the MRC implementation? Is this entirely
> >> invisible to ath9k, or is this implemented / supported in software?
> > 
> > No, frankly this is the first time I read about MRC.
> > I just poked a few guys here about MRC and got the clarification
> > above.
> 
> Right - so the MRC functionality is in the chip's DSP and entirely
> invisible to the software? Yes? Just being 100% clear here...

Beats me. I haven't dealt with MRC at all in software so I guess.

> >> And to be clear, you think the 802.11n chipsets before the
> >> AR9300 *do not* include TxBF at all? Not that it simply isn't
> >> supported by the drivers?
> > 
> > Only a legacy (802.11g) end of life'd device had some form
> > of Tx beamforming, but that's not even supported and its easier
> > to just assume no chipset supports it other than the shiny
> > new AR93xx family.
> 
> Right - and as discussed, TxBF has less benefit than with 802.11n.

Oh?

> Since then, I have looked at some Matlab simulations here and seeing
> that 2 antenna MRC can slightly outperform 2 antenna TxBF. 

Good to know, can you publish your results while at it.

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

>> Right - so the MRC functionality is in the chip's DSP and entirely
>> invisible to the software? Yes? Just being 100% clear here...
> 
> Beats me. I haven't dealt with MRC at all in software so I guess.
> 
 And to be clear, you think the 802.11n chipsets before the
 AR9300 *do not* include TxBF at all? Not that it simply isn't
 supported by the drivers?
>>> 
>>> Only a legacy (802.11g) end of life'd device had some form
>>> of Tx beamforming, but that's not even supported and its easier
>>> to just assume no chipset supports it other than the shiny
>>> new AR93xx family.
>> 
>> Right - and as discussed, TxBF has less benefit than with 802.11n.
> 
> Oh?

This is a typo. But my point is that when you have 2x2:2, MRC, multiple spatial 
streams, etc. adding TxBF to the equation doesn't achieve the same kinds of 
gains for mid to high bitrate situations you see when you drop a TxBF 802.11g 
system into place. 

At least that's my understanding... I haven't actually modeled all of these 
variables together into a full system.

>> Since then, I have looked at some Matlab simulations here and seeing
>> that 2 antenna MRC can slightly outperform 2 antenna TxBF. 
> 
> Good to know, can you publish your results while at it.

I was only playing with MRC versus TxBF in 2x2 configurations. My data isn't 
conclusive enough to be published and didn't look at them in combination.

Mostly, I was trying to answer the question, why would they drop TxBF from 
802.11n chipsets? Did we end up with a worse performing product? And the 
conclusion was that MRC probably equals or beats TxBF. e.g. client with MRC 
connected to non-TxBF AP should achieve similar to slightly better performance 
than a non-MRC client with a TxBF AP, resulting in significant reception gains 
for virtually all stations versus a non-MRC chipset. Conversely, TxBF would 
only help with transmit, which is usually much less data intensive than receive 
for most users (e.g. station mode client radios in notebooks, desktops, phones, 
etc.) I also suspect that MRC makes it easier to deal with cheap / crappy 
hardware implementations - cheap amplifiers, suboptimal antennas, etc.

So if you want a fast performing chipset and have a 
time/dollar/power/complexity budget to meet, MRC is a better choice for most of 
your customers most of the time. Or at least that's my take on it. 

All that said, AR9003 will still be warmly welcomed. I'm not arguing that TxBF 
is useless, just not quite as overwhelmingly valuable as it once was. (This is 
highly context sensitive though, as 3x3 802.11n APs with 802.11g clients will 
probably see big gains, but 3x3 802.11n to 3x3 802.11n will not see as much, 
and at extreme range, the TxBF may also keep a very slow connection alive 
longer.)

It's pretty hard to encapsulate all this effectively into text, and I don't 
know that I have the time or expertise to build out and publish extensive 
simulations but I hope this makes some sense.

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

On Feb 26, 2010, at 8:42 AM, Luis R. Rodriguez wrote:

> On Thu, Feb 25, 2010 at 08:03:57PM -0800, Galen wrote:
>> I am aware of the AR9300 features / SST3.
>> 
>> The AR9100 and AR9200 also contains SST
> 
> Oh? I thought SST thing was the marketing name for our
> full solution of 3 stream for 802.11n.
> 
>> It is not always mentioned, but it is present in many different
>> specifications I have seen for the AR9100 and AR9200 family of
>> chipsets. I think there is some discussion still as to what SST is, 
>> however...
> 
> Again, I thought it was just our full 3 stream stuff.


I honestly don't know - but I know SST was marketed with the 3x3 AR5008 
chipsets, so I assume SST3 probably is talking about the new TxBF, ML, LDPC, 
etc. Now we have AR9003 which is being marketed with SST3. Was there ever an 
SST2? I have no clue. The AR9001 and 9002 chipsets seem to also have SST, but 
it wasn't marketed heavily like the AR5008.

I just get tired of playing mystery meat features / mystery meat marketing BS 
with Atheros.

-Galen
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Luis R. Rodriguez]

Note: this thread is on a public mailing list!

I've added a few marketing folks.

On Fri, Feb 26, 2010 at 3:11 PM, Galen  wrote:
>
> On Feb 26, 2010, at 8:42 AM, Luis R. Rodriguez wrote:
>
>> On Thu, Feb 25, 2010 at 08:03:57PM -0800, Galen wrote:
>>> I am aware of the AR9300 features / SST3.
>>>
>>> The AR9100 and AR9200 also contains SST
>>
>> Oh? I thought SST thing was the marketing name for our
>> full solution of 3 stream for 802.11n.
>>
>>> It is not always mentioned, but it is present in many different
>>> specifications I have seen for the AR9100 and AR9200 family of
>>> chipsets. I think there is some discussion still as to what SST is, 
>>> however...
>>
>> Again, I thought it was just our full 3 stream stuff.
>
>
> I honestly don't know - but I know SST was marketed with the 3x3 AR5008 
> chipsets, so I assume SST3 probably is talking about the new TxBF, ML, LDPC, 
> etc. Now we have AR9003 which is being marketed with SST3. Was there ever an 
> SST2? I have no clue.

No but it may be used later it seems.

>The AR9001 and 9002 chipsets seem to also have SST, but it wasn't marketed 
>heavily like the AR5008.
>
> I just get tired of playing mystery meat features / mystery meat marketing BS 
> with Atheros.

Heh, well I tend to focus on the software and not the marketing names
for technologies. But it seems you're right, I checked with Marketing
and indeed SST, "Signal-Sustain Technology" was used to "enhance
signal reliability and throughput at range" for AR5008, launched in
2006. Since then we have not used the same brand name for any other
family of chipsets except for the the 9300 with which we revived the
brand.

Quoting some more:

"Signal Sustain Technology (SST) dramatically increases link
robustness and throughput (Note: we just do it differently)by
simultaneously transmitting across three spatially-diverse signal
paths, and incorporating information from three receivers
simultaneously within the signal processing at the receiver. Such
robustness cannot be achieved by simply switching a smaller number of
simultaneous transmitters between additional antennas. Atheros'
integration of three complete RF transmit and receive chains into a
single chip, together with the inclusion of the SST processing in the
baseband, enables unmatched range and robustness at price points
comparable to less robust, competitive 2x2 MIMO solutions.

Now, the definition of SST is the combination of a variety of optional
11n features which enhance link robustness (LDPC, TxBF, MLD)...it is
not reliant on the 3-streams, per se."

  Luis
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Björn Smedman]

Hi Galen,

Any progress? Have you had a chance to test your setup with Felix's
Minstrel rate selection patch? Better rate selection might be part of
the solution.

Also, I think Felix is working on STBC support. That should really help.

/Björn

On Sun, Feb 21, 2010 at 9:41 PM, Galen  wrote:
>
> Hello All,
>
> I have been testing out ath9k in a variety of situations. I have observed it 
> appears to have poorer handling in MIMO-intensive environments than the 
> binary drivers under Mac OS X and Windows. I have two computers with 
> identical radios (3x3:2 AR5008 Mini PCI-e) and as similar of antenna 
> configurations as possible. One computer runs Windows XP + latest Atheros 
> binary drivers and Linux 2.6.32 + latest compat-wireless. (I have also tested 
> some older versions with similar results.) The other computer runs Mac OS X 
> 10.6.2 which contains the latest Atheros binary drivers.
>
> The APs are a mix of 5 GHz 802.11n and 802.11a, from multiple vendors and 
> with varying chipsets including Atheros and Broadcom. I have tested 
> greenfield/non-greenfield 802.11n modes and both 20 MHz and 40 MHz channels 
> and seen similar results in all cases. In all my tests, I have a virtually 
> 100% noise-free environment, non-overlapping channels, no traffic on the APs 
> except the testing computers. Never has any card reported a noise value above 
> the thermal/amplifier chain noise floor. There are no known 5 GHz 802.11 APs 
> except for those under my control operating within 1 km.
>
> The conclusion I am reaching is that in clean line of sight situations, the 
> Linux ath9k performs as expected - almost perfectly identical to the OS X and 
> Windows tests. However, as you lose line of sight and/or have increased 
> multi-path, Linux / ath9k quickly falls dramatically behind the binary 
> drivers in Windows and OS X. And unfortunately, in almost all real-world 
> situations, multi-path is present and a major factor.
>
> *** Situation A ***
> The OS X computer picks up a remote non-LoS 5 GHz 802.11n AP without any 
> problems and associates reliably. Depending on precise location, signal 
> strength varies from -72 dBm to -88 dBm and typically I see MCS 3-7. Windows 
> detects the AP but does not reliably associate with it. Linux does not even 
> detect the AP.
>
> *** Situation A-2 ***
> Switching out the AR5008 for a high-quality AR9280 (2x2:2) does allow Linux 
> to detect the remote non-LoS AP, but it still cannot associate reliably at 
> that location. The AR9280's increased sensitivity seems to allow the 
> detection of APs in more edge situations, but does not significantly improve 
> non-LoS performance. Additional, in other limited tests, the AR9280 often 
> yields significantly worse signal levels as compared to the AR5008 - 
> sometimes 10 to 20 dB worse.
>
> *** Situation B ***
> Testing against a very close 802.11n AP, Linux has extreme difficulty dealing 
> with the strong multipath. Linux reports a signal of around -72 to -74 dBm 
> and maintains a much lower bitrate with a "link quality" around 70/100. This 
> is low enough that link speed is significantly reduced, with either low MCS 
> (usually <4) or even dropping to 6 megabit 802.11a occasionally. By 
> comparison, Linux sees an identical AP a few rooms over attains a signal 
> strength around -50 to -55 dBm and a link quality of 80-90/100, and operates 
> at full bitrate or near full bitrate. (The performance with the 2 rooms away 
> AP is similar to Windows and OS X, one of the few non-LoS situations where 
> Linux ath9k can match Windows and OS X.)
>
> For comparison, Windows and Mac OS X both attain a 270 megabit (MCS15) 
> connection and hold it fairly reliably (occasionally and only briefly 
> dropping to MCS13 or MCS14) with signal in the -30s and lower -40s range. The 
> relative link quality is somewhat lower than when a little further from the 
> AP or with a bit less multi-path, but OS X and Windows both maintain near 
> full bitrate and perform quite acceptably.
>
> *** Situation C ***
> Testing against an 802.11a AP in an adjacent room with directional antenna 
> pointed away from the indoors testing location. This means all signal is 
> multi-path. The Linux computer cannot reliably associate with the AP. During 
> association attempts, the Linux computer reports signals in the -82 to -88 
> dBm range and link quality from 34/100 to 54/100. The Mac OS X computer 
> reports a signal strength of -45 to -50 dBm, associates reliably, and attains 
> full 802.11a bitrate. Windows is similar to slightly behind OS X in this case.
>
> *** Further Testing ***
> I plan to create a triple-boot environment so I can compare any OS 
> combination on exactly the same hardware. Absolute care will be used when 
> rebooting as not to move anything. I will run a standard series of network 
> tests under Linux and OS X. (It is a significantly larger headache to setup 
> Cygwin to use the same tools on Windows and I will only do so if OS X