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