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 mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
