[ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers

[Felix Fietkau <nbd@openwrt.org>]

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