[ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[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@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 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.

Can anybody comment on this issue? Have you experienced it yourself?

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.

-Galen

[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] 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] 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 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.

- Felix

[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] 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] 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] 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] Ath9k MIMO Performance versus Proprietary Drivers

[rootkit85 at yahoo.it]

On Wed, Feb 24, 2010 at 8:41 PM, Galen <galenz@zinkconsulting.com> 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 at 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] Ath9k MIMO Performance versus Proprietary Drivers

[Galen]

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

> On Wed, Feb 24, 2010 at 8:41 PM, Galen <galenz@zinkconsulting.com> 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] 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] 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] 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 <galenz@zinkconsulting.com> 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] 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] 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] 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] 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) <http://portal.acm.org/citation.cfm?id=1672308.1672313> or off my website <http://www.cs.washington.edu/homes/dhalperi> direct PDF link: <http://www.cs.washington.edu/homes/dhalperi/pubs/mimo_for_dummies.pdf> .

[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) <http://portal.acm.org/citation.cfm?id=1672308.1672313> or off my website <http://www.cs.washington.edu/homes/dhalperi> direct PDF link: <http://www.cs.washington.edu/homes/dhalperi/pubs/mimo_for_dummies.pdf> .

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] 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) <http://portal.acm.org/citation.cfm?id=1672308.1672313> or off my website <http://www.cs.washington.edu/homes/dhalperi> direct PDF link: <http://www.cs.washington.edu/homes/dhalperi/pubs/mimo_for_dummies.pdf> .
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[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] 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] 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] 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 <galenz@zinkconsulting.com> 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@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 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.
>
> Can anybody comment on this issue? Have you experienced it yourself?
>
> 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.
>
> -Galen
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel