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
