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
