Re: [ath9k-devel] Proposed 3x3 Dual band chipsets
On May 30, 2012, at 10:57 AM, Stratos Keranidis wrote: Hello, I am about to order some new cards for testing capabilities of ath9k. Currently I have cards with the AR5008, AR5418 chipset, which does not support 3x3 MIMO. I looked in the list of ath9k-supported chipsets to find cards that support 3x3 MIMO and I have concluded in the following options: AR5008: AR5418+AR5133 (= 2.6.27) AR5418 = DB 11n PCIe, AR5133 = 3x3 DB 11n AR5416+AR2133 (= 2.6.27) AR2133 = 3x3 SB 11n AR9001: AR9103 (= 2.6.30, AHB) 3x3 SB 11n AR9003: AR9380 (= 2.6.36) 3x3 DB 11n PCIe My AR5418 card supports Dual Band operation, but I am not able to set 5GHz channels in my regulatory domain (GR). As I am interested in buying Dual-band compatible chipsets only, my options are limited between the AR5008:AR5133 and the AR9003:AR9380 chipsets. Can you propose any of these, or any other chipset that might fit my needs? Thank you in advance, Stratos This may be helpful reading: http://en.wikipedia.org/wiki/802.11n#Number_of_antennas You want to go with a AR9003, probably AR9380. It supports true 3x3:3 configurations. This means it has the ability to transmit on 3 antennas at once, or receive on 3 antennas at once. It can also handle 3 spatial streams, meaning you can get up to 450 megabits per second with 40 MHz channels. It also features superior DSP to better process the MIMO signals and beamforming to aim the signal. The AR9001 family of chipsets are much more limited. They cannot handle 3 spatial streams, so you cannot get more than 300 megabits. I am not sure about the 3x3 capabilities on the AR9103 but I know they are much inferior to the AR9003 family. I am not even sure if they are really processing the signal with DSP or if they are just switching between antennas intelligently. In any case, the AR9003 has immense improvements on every front as compared to AR9001. The AR5008 family is best avoided if you are buying a new card. I believe they do not consider this card fully supported in ath9k. It does work. I think there may still be some bugs left. I believe the 3x3 is really just 2 transmitting that switches between antennas intelligently. As for the AR9380, it is a single-chip solution. Amplifier, everything on a single chip. As a result, there will be vastly less variation from brand to brand. I would just look for a cheap one on eBay. They are $30 on eBay. The SparkLAN products are also solid, but may be more expensive. I have not evaluated sufficiently to see if there is any benefit. As for the regulatory stuff - search the list and also check with OpenWRT. There are many ways to make the radio function on whatever channel you wish. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Any 4x4 MIMO ath9k NICs coming soon?
As far as I know, Quantenna is the only producer of 4x4:4 chipsets. Some other companies have 4x4 chipsets that are 4x4:3 and simply use the additional antenna for beamforming, diversity, etc. Historically, Atheros has begun chest-beating about chipsets significantly in advance to their release. I think the AR9003 platform started being talked about it in general term around 18 months prior to general market availability of AR9003 products. I suspect you will have a very long wait if you are counting on Atheros (now Qualcomm) for 4x4 solutions. Interestingly, Qualcomm did announce 4x4:4 solutions a few years ago, but nothing came of them. They since acquired Atheros, so I suspect their internal 802.11 products were very unimpressive or even deeply flawed. The reality is that 4x4:4 solutions really provide diminishing improvements relative to cost. Every additional spatial stream causes a more than linear increase in DSP complexity, a linear increase in radio/amplifier cost, a slightly more than linear increase in power consumption (radio/amplifier+DSP), and an increase in PCB footprint. And for all this extra hassle and cost, you get a typically less-than-linear increase in throughput. The gains from jumping from 1x1:1 to 2x2:2 were huge, each increment above that is simply a lot less bang for your buck. I'm not saying it'll never happen, but the deck is somewhat stacked against 4x4:4 solutions. I think 802.11ac will very quickly emerge as the preferred means of adding bandwidth, with 4x4:4 being something that continues to slowly grow and only becomes seen much in the wild when 802.11ac hits. Note that Quantenna has already updated their 4x4:4 chipsets to support 802.11ac. -Galen On Jan 17, 2012, at 9:12 AM, Ben Greear wrote: I've some customers asking for 4x4 MIMO support for our wifi testing gear (which requires the ath9k virtualization features). Anyone know if Atheros is going to be offering a 4x4 MIMO solution anytime soon? Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ 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
Re: [ath9k-devel] Any 4x4 MIMO ath9k NICs coming soon?
Ben's company focuses on load testing applications, so I assume he's referring to 4 spatial stream systems. 4x4:4 specifically refers to 4 transmit, 4 receive and support for 4 spatial streams. The only commercially available chipset for 802.11n is from Quantenna. There are 4x4:3 802.11n chipsets available which use the extra radio for beamforming and diversity, but these are not 4 spatial stream. You get an improvement in terms of RF performance, but the MAC layer and throughput is essentially the same as 3x3:3 solutions like AR9380 and AR9390. Since Ben's application is primarily focused on these layers as far as i know, I assumed he was looking for 4 spatial streams. Keep in mind, beamforming and diversity is very much possible within implementations the 802.11n specification. The only thing really novel to 802.11ac is the addition of optional downlink MU-MIMO. -Galen On Jan 17, 2012, at 1:39 PM, Adrian Chadd wrote: Well, are you talking about: * 11n 4x4 MIMO? * 11ac Multi-user MIMO (where you map stations to separate spatial streams?) * other beamforming/diversity stuff? Adrian On 17 January 2012 11:51, Galen gal...@zinkconsulting.com wrote: As far as I know, Quantenna is the only producer of 4x4:4 chipsets. Some other companies have 4x4 chipsets that are 4x4:3 and simply use the additional antenna for beamforming, diversity, etc. Historically, Atheros has begun chest-beating about chipsets significantly in advance to their release. I think the AR9003 platform started being talked about it in general term around 18 months prior to general market availability of AR9003 products. I suspect you will have a very long wait if you are counting on Atheros (now Qualcomm) for 4x4 solutions. Interestingly, Qualcomm did announce 4x4:4 solutions a few years ago, but nothing came of them. They since acquired Atheros, so I suspect their internal 802.11 products were very unimpressive or even deeply flawed. The reality is that 4x4:4 solutions really provide diminishing improvements relative to cost. Every additional spatial stream causes a more than linear increase in DSP complexity, a linear increase in radio/amplifier cost, a slightly more than linear increase in power consumption (radio/amplifier+DSP), and an increase in PCB footprint. And for all this extra hassle and cost, you get a typically less-than-linear increase in throughput. The gains from jumping from 1x1:1 to 2x2:2 were huge, each increment above that is simply a lot less bang for your buck. I'm not saying it'll never happen, but the deck is somewhat stacked against 4x4:4 solutions. I think 802.11ac will very quickly emerge as the preferred means of adding bandwidth, with 4x4:4 being something that continues to slowly grow and only becomes seen much in the wild when 802.11ac hits. Note that Quantenna has already updated their 4x4:4 chipsets to support 802.11ac. -Galen On Jan 17, 2012, at 9:12 AM, Ben Greear wrote: I've some customers asking for 4x4 MIMO support for our wifi testing gear (which requires the ath9k virtualization features). Anyone know if Atheros is going to be offering a 4x4 MIMO solution anytime soon? Thanks, Ben -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ 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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Maximum Radio Limit?
On Aug 28, 2011, at 10:08 PM, Alex Hacker wrote: On Fri, Aug 26, 2011 at 11:27:26AM -0700, Galen wrote: Provided that enough PCIe ports are available, along with sufficient memory and CPU, is there any limit to the number of radios that can be supported by ath9k and mac80211? Are there any design bottlenecks in the software that would be problematic in the context of a system with 100s of ath9k radio modules from being active simultaneously? -Galen Hi Galen! What you trying to build? This is a military or intelligence project? :) Such crazy platform should be expensive, thousands of USD I think. Regards, Alex. I've already looked at the costs - thankfully AR9003 radio modules are not very expensive. I'm also aware of the various RF considerations with all those radios co-located. If you or anybody wants to discuss my goals in more detail, please contact me off-list. I'd be happy to share with you more, but I don't want to get too far off-topic on the mailing list. Back to the question: anybody have thoughts on potential design limitations? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Maximum Radio Limit?
Provided that enough PCIe ports are available, along with sufficient memory and CPU, is there any limit to the number of radios that can be supported by ath9k and mac80211? Are there any design bottlenecks in the software that would be problematic in the context of a system with 100s of ath9k radio modules from being active simultaneously? -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Hot Plug / Hot Swap Support?
Is it possible to add and/or remove ath9k-supported radio modules without reloading compat-wireless? The ideal arrangement in this context would be to have multiple radio modules installed in a single system and then selectively add and/or remove one module at a time without disrupting connectivity for the other active modules. Any thoughts? If this is not implemented, any idea how difficult this would be to make happen? -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] What wireless adapter should I use
On Aug 20, 2011, at 2:22 PM, austin wonderly wrote: I am currently using a dlink dwa552 which seems to make hostapd highly unstable :/ I would really appreciate some advice as hostapd seems like a sort of niche program so I cannot find any other advice on Google :/ I am mostly just looking for a wireless n pci adapter I believe that is an AR5008-based product. I would suggest you look at AR92xx-based solutions (AR9002 platform.) The ath9k drivers are much better. Try any of Ubiquiti's miniPCI products with a miniPCI to PCI adaptor. They work extremely well. I would suggest that you move this discussion over to the ath9k mailing list. I've copied them on this email (and NOT copied the hostapd mailing list) and I would suggest that you join that list if have not already done so. -Galen___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k: Network stalls every 30 seconds
I haven't reviewed the full thread here - but have you made 100% sure that there is not some kind of WiFi connection manager running in the background on the Linux system? Just something to double check... those connection managers frequently probe and cause network stalls, particularly at specific, likely human-programmed intervals (e.g. 30 seconds) like you're describing... Sure, it's stupidly simple, but Linux distros have deeply embedded WiFi connection managers and people sometimes miss them... -Galen On Aug 8, 2011, at 6:13 PM, Adrian Chadd wrote: .. sorry, he isn't having issues with the AR5416 on FreeBSD but is under ath9k. (Wow, is this the second time FreeBSD works where ath9k doesn't? I may have to throw a little private party :-) Would someone like to take up the challenge? I'll help you wade through the HAL if you'd like. Adrian On 9 August 2011 09:12, Adrian Chadd adr...@freebsd.org wrote: Hi all, I'm just forwarding what Robert said. FreeBSD doesn't have the same interruptions as ath9k does on the AR5416. I don't have the time to go digging myself just now. On 3 August 2011 05:37, Robert Högberg robert.hogb...@gmail.com wrote: An update to previous mail.. I tried the i386 version of FreeBSD 9.0 beta (instead of amd64) and that one worked much, much better. No network interruptions every 30 seconds in FreeBSD 9.0 beta 1, but I only ran the test for a few minutes. Would you expect the noise floor calibrations to happen every 30 seconds in FreeBSD also or is the interval different there? I'll continue investigating. (You may want to look into why the ath driver doesn't work on amd64..) Robert 2011/8/2 Robert Högberg robert.hogb...@gmail.com: I tried FreeBSD and the computer crashed when I tried to enable the WLAN. I'm no FreeBSD user so I'm not sure I got things right, but here's what I did: * Boot FreeBSD from USB stick (WLAN device was detected correctly and ath0 created) * ifconfig wlan0 create wlandev ath0 * ifconfig wlan0 up (This caused the computer to freeze. No output, and no input possible. I waited minutes but nothing happened.) I attach dmesg output after boot. /Robert 2011/8/2 Adrian Chadd adr...@freebsd.org: Ah, that it works well in Windows is a good sign. Would you mind doing me a favour? Could you spin up FreeBSD-9.0-BETA1 on a temporary disk (eg a USB thumb drive) and see if it exhibits the same behaviour? Adrian On 2 August 2011 04:19, Robert Högberg robert.hogb...@gmail.com wrote: 2011/7/30 Adrian Chadd adr...@freebsd.org: Have you tried another ath9k NIC? Another AR5416 NIC? I've tried an AR9271 NIC (USB ID 0cf3:9271) and it works very well. I only have one AR5416 NIC to test I'm afraid. Is it possible this NIC is slightly weirdly damaged? Maybe, but the card works well with the Windows 7 drivers. But I guess it's possible that the noise floor calibration functionality is broken/problematic on this card and the Windows driver knows this and avoids or adapts to the problem. After all, I don't see any problems with the calibration disabled so maybe the Windows driver doesn't use the calibration either. But I don't know.. TP-Link has released a v2 version of this TL-WN851N NIC (I'm using v1) which suggests the first version may not have been perfect. Maybe v1 was weirdly damaged and they fixed it in the second version. I don't know what the differences are between the two versions, but I think they used AR5416 in both versions. Robert ___ 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
Re: [ath9k-devel] 1 antenna 300Mbps? Also: interference.
A few notes: 1) Always connect both antennas. They are necessary to achieve 300 megabits, and overall improve robustness significantly. 2) Make sure that you use channels as far apart as possible. e.g. ideally channel 1 for one radio, channel 11 for the other. At the very least, channel 1/6 or 6/11. 3) I would try out the real world situation before you worry too much about lowering power. Space the cards and antennas a bit apart if possible in the case, but otherwise just try it out. -Galen On Jul 29, 2011, at 4:59 PM, Grant wrote: The SR71-E is a high power NIC. Having two of them close by and on similar frequencies is ilkely going to piss each other off. It puts out 26dBm at low TX power (400mW +/- 2dB according to the specifications.) Should the problem be solved if I do something like 'iwconfig wlan0 txpower 0'? You may be able to get away with it if one is on 2ghz and one is on 5ghz, but there's still a lot of high powered RF being pumped out. If you separated the antennas (ie, look at how APs like Cisco 11n dual-band APs work) then you may have some better luck? (Note: I'm not an electrical engineer or RF engineer, I'm just echoing personal experience here. I also know a dlink DIR-825 AP works with both of the 2ghz/5ghz AR9220's linked to the same two antennas, but they're not pumping out the same amount of power as an SR71-E.) And yes, you need both antennas connected and working on an SR71-E to achieve MCS15 (300mbit.) All two stream rates require both antennas to be connected. Got it, thanks. - Grant Adrian On 30 July 2011 07:06, Grant emailgr...@gmail.com wrote: Can I expect to connect at 300Mbps with my Ubiquity SR71-E if I only connect one of the antennas if my AP is sufficiently nearby, or does 300Mbps necessitate the use of 2 or more antennas? My desktop system has an ath5k card which works great unless I also install my Ubiquity SR71-E ath9k card. With both installed, the ath5k card frequently drops the connection. I was planning on eventually removing the ath5k card and installing 2 Ubiquity SR71-E cards and turning that system into a router with one card connected to the LAN and one connected to the WAN via a D-Link wireless bridge. Would that scenario work or would the two cards interfere with each other too much? - Grant ___ 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
Re: [ath9k-devel] 802.11n PCI-E 300Mbps with AP mode?
On Jul 13, 2011, at 4:42 PM, Grant wrote: Again, anything with an AR9280 on board will be fine. Some of the antenna arrangements though are a bit .. special. I'm told this one fits the bill: http://www.tp-link.com/products/productDetails.asp?pmodel=TL-WN951N It is said to have a AR5008 chip. Can anyone confirm that this card works in AP mode? - Grant As many have said, yes, the AR5008 chipset works in AP mode - but it is older than the AR9280 and has some quirks. Also, a warning, I have found that many vendors who make PCI/PCIe cards have a bad habit of switching around the chipsets without warning customers. Unless a vendor themself markets the product based on the specific chipset, I try not to trust the random chance of whatever hardware revision I might (or might not) find when I buy the product. I am behind the many who have said - why not an adaptor? I use them regularly and the cards screw easily and securely into the adaptor without exceeding the thickness of a normal card, and the adaptor provides nice antenna ports on the back of the card. Many adaptors even bundle antennas, so you don't need to buy anything else. I hope this helps... ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] 802.11n PCI-E 300Mbps with AP mode?
It sounds like you are looking for a PCIe, not miniPCIe solution. If that is the case, it may be easiest to buy a PCIe to miniPCIe adaptor card off eBay for about $10 (US), then buy whatever miniPCIe card you like as there are a lot more models available in that form factor. A favorite of mine is the Ubiquiti SR71-E, a very high power, high-sensitivity dual-band AR9280 solution. It costs around USD $60. It manages to hold MCS15 at -70 dBm very reliably for me. I think it's the best AR9280 module on the market - but if I'm wrong, I'd love to be corrected :-) You can also get other AR9280 solutions widely on eBay - but the quality varies widely in my experience. -Galen On Jul 12, 2011, at 3:10 PM, Grant wrote: Is there an 802.11n PCI-E ath9k card available that does 300Mbps and works in AP mode? - Grant ___ 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
[ath9k-devel] AR9003 / AR9002 / AR5008 Testing Environment Available
A number of mailing list members have expressed interest in AR9003-based hardware. At this time, I only have a very limited quantity of these cards on-hand (sample production cards), so I need to hold on to them for my own purposes and don't have any extras yet. However, if anybody has the need for testing with Atheros hardware to further ath9k-related development or improvements, particularly the new AR9003 hardware, I can provide ssh access to test systems in the near future. I'm making this available in the interests of furthering ath9k. I have AR9003 (AR9380 3x3:3) cards, AR9002 cards (AR9280, AR9281), and AR5008 cards (AR5BXB72-type 3x3:2) available, all of which would be connected via PCIe. I can configure anywhere from 1 to 4 radio cards per system, and any reasonable number of systems you desire. I can provide you with a defined range of channels in the 5 GHz band that are free of other users and essentially interference-free. If useful for cross-testing, I may be able to also install a few other cards, such as Intel 5300 (3x3:3), Broadcom, and some older ath5k cards. Access to a Ubiquiti Nanostation M5 (AR9280 with proprietary Linux binary drivers that include things like spectral scanning, reduced channel widths, and more) can also be arranged via web GUI and SSH. You would be free to do anything you like to the systems. All systems will be non-critical testing systems, and I would provide root access so you can install things / hack / break the system as needed. If you break the system, I can re-image the whole system to fresh in a matter of minutes. If you have specific requests, please contact me off-list with the nature of your testing objectives and requirements (functionality you're working on, desired hardware configuration) and some idea as to how much time you think you'll need. I should be able to facilitate remote access testing starting sometime next week, and I am thinking that I may be able make testing systems available mostly continuously for weeks or possibly months. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] RIFS Support
On Jan 6, 2011, at 1:21 PM, Luis R. Rodriguez wrote: On Thu, Jan 6, 2011 at 10:29 AM, Galen gal...@zinkconsulting.com wrote: Last I checked, RIFS support was not implemented in ath9k. Is the lack of support due to mac80211 limitations, or due to ath9k limitations? RIFS support can be enabled for AR9003 but there has been no interest for it as its not widely used. Are you interested in implementing support for it on mac80211? Luis I am involved with a project looking to make extensive use of ath9k with AR9003/AR9002 hardware. Provided the project continues to move forward, we will be looking to put some material resources into developing the missing features that are of interest for our application, with the intent of getting them committed to ath9k / mac80211. We are particularly interested in features that affect performance in the STA/AP relationship. As of now, my working list of features of interest: - RIFS - 5/10 MHz channels - Possible improvements to rate control model (or possibly better hooks for external code) - AR9003 AMSDU TX - AR9003 LDPC - AR9003 STBC - AR9003 TxBF I suspect some of the AR9003 issues will be sorted out by people already on the project, but other issues such as RIFS, 5/10 MHz channels, etc are very likely to require efforts on our part to see implemented. AR9003 parts are only starting to become available in pre-production units, and the internal documentation is obviously a barrier to outside efforts on the code development. I will be inquiring about others on this mailing list over the next few days. I am trying to keep those in separate threads. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Greenfield Support
What is the status of true Greenfield support in ath9k with AR9002/AR9003? Basic tests with hostapd, ath9k, etc. seem to show that it is not working with AR9280. However, this could be a hardware or software (ath9k, mac80211, hostapd) issue. The key interest here is reducing the time overhead of the preamble / PLCP for each frame. Obviously, this is not appropriate in all situations, but for some, it can be useful. Can anybody clarify the status of this? -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k: A-MSDU Size A-MPDU TX
What determines the maximum A-MSDU size for a given ath9k radio? For example, most (or all?) of my ath9k radios (AR5008, AR9280) seem to report an A-MSDU limit of 3839 bytes. However, the 802.11n specification allows up to 7935 bytes. Is this a true hardware limitation? Does it apply to all ath9k hardware? (Including AR9003/AR9380) Also, it appears that A-MPDU is entirely unsupported, at least for transmit purposes. It appears to be supported for receive purposes, but several posts say this is untested. Is the lack of TX A-MPDU a hardware or software limitation? Does it apply to all ath9k hardware? If it is a software issue, what is the barrier to implementation / complexity involved? Of note, I am aware that A-MPDU is of somewhat limited use for many applications, so no need to explain why it is not very useful... :) -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Simultaneous 2.4 and 5.8 GHz on AR5008
On Oct 14, 2010, at 10:11 AM, Artem Makhutov wrote: Hello, is it possible to create an AP for 2.4 and 5.8 GHz simultaneous using a AR5008-3NX, MAC AR5416, AR5133 (ATHEROS AR5BMB-0072TA) card? Please set me on cc when replying, as I am not subscribed to the list. Thanks, Artem This is not possible. Many 802.11n radios are dual-band (including AR5008-3NX) - however, they can only operate in one band at a time. It is not practical for the radio to rapidly switch between bands. Even if you setup a system where it scheduled data transmits, data receives would be highly problematic to schedule. In theory this might be possible, but there is no good software available because it would either fail in practice, or be plagued with massive performance and/or reliability problems. 802.11 is simply not designed for the AP to vanish periodically. What you require is simultaneous dual band, which means the radio can operate in both bands at the same time. There are very few if any radio modules available that support this. I believe a few may have been produced - but they would be a rarity. I would suggest using multiple radios if you require dual-band support. They are quite inexpensive. Simply set each one up as an AP. If you do not have enough slots, there are a variety of options for multiplying PCI slots that are quite affordable. However, options for PCIe are somewhat limited. I hope this helps. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Simultaneous 2.4 and 5.8 GHz on AR5008
On Oct 14, 2010, at 12:44 PM, Artem Makhutov wrote: Hello, Galen schrieb: On Oct 14, 2010, at 10:11 AM, Artem Makhutov wrote: Hello, is it possible to create an AP for 2.4 and 5.8 GHz simultaneous using a AR5008-3NX, MAC AR5416, AR5133 (ATHEROS AR5BMB-0072TA) card? Please set me on cc when replying, as I am not subscribed to the list. Thanks, Artem This is not possible. Many 802.11n radios are dual-band (including AR5008-3NX) - however, they can only operate in one band at a time. It is not practical for the radio to rapidly switch between bands. Even if you setup a system where it scheduled data transmits, data receives would be highly problematic to schedule. In theory this might be possible, but there is no good software available because it would either fail in practice, or be plagued with massive performance and/or reliability problems. 802.11 is simply not designed for the AP to vanish periodically. What you require is simultaneous dual band, which means the radio can operate in both bands at the same time. There are very few if any radio modules available that support this. I believe a few may have been produced - but they would be a rarity. I would suggest using multiple radios if you require dual-band support. They are quite inexpensive. Simply set each one up as an AP. If you do not have enough slots, there are a variety of options for multiplying PCI slots that are quite affordable. However, options for PCIe are somewhat limited. I hope this helps. Thank you for the info. What are the solutions to multiply a miniPCI slot? Thanks, Artem Consider the following options: http://www.redpinesignals.com/Solutions/Reference_Designs/Smart_Grid_Comm/RS-SE-601.html http://www.sparklan.com/product.php?func=viewprod_id=43 I don't know about the best choices for multiplying a miniPCI slot, one choice is this, paired with PCI-miniPCI adaptors. Only useful if you have space: http://www.globalamericaninc.com/p1800010/1800010_-_Mini-PCI_Type-III_Module_to_PCI_Adapter_Card/product_info.html There are probably many other resources out there too that I haven't listed. The SparkLAN product is notable as it is not very expensive. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k RIFS Status?
On Sep 27, 2010, at 7:41 AM, Senthilkumar Balasubramanian wrote: On Sun, Sep 26, 2010 at 2:48 AM, Galen gal...@zinkconsulting.com wrote: On 2010-02-24 Luis Rodriguez wrote this regarding RIFS support: Not 100% sure but I actually think we do have it enabled for single-chip solutions and I think it should work. RIFS RX should work and we have tested it earlier and ath9k does not support RIFS Tx. Thank you for the clarification. Is this a hardware or software limitation? Since we are already varying the inter-frame spacing for WMM, is there a particular reason one couldn't get RIFS to work?___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] ath9k RIFS Status?
On 2010-02-24 Luis Rodriguez wrote this regarding RIFS support: Not 100% sure but I actually think we do have it enabled for single-chip solutions and I think it should work. From my understanding of the 802.11n specification, when operating in Greenfield mode, RIFS can be utilized when there is no ACK expected. Is this supported in ath9k for AR9002 or AR9003? I briefly reviewed the code, but there aren't a lot of clear references to RIFS or comments. e.g. ar9002_phy.h: #define AR_PHY_HEAVY_CLIP_FACTOR_RIFS0x99EC #define AR_PHY_RIFS_INIT_DELAY 0x03ff If RIFS is enabled, I can only imagine that it is handled at the chipset level because I can't really find any other supporting code involving RIFS - e.g. when the IEEE80211_TX_CTL_NO_ACK flag is set, the hardware automatically uses RIFS? Can anybody clarify? Point me to the relevant code? -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Status of DFS / TPC in ath9k
What is the status of DFS? (Dynamic frequency selection for radar avoidance.) At one point, Alexander Egorenkov had pulled out some of the function from BSD drivers, for Robert Meschke who had some interest in possibly implementing it. (He implemented in madwifi previously.) Luis Rodriguez seemed to suggest that additional software was required from upstream, but was not clear what. DFS requires some software implemented which is not upstream, we are reviewing this possibility now. What is the status of DFS now? Any prospective means for it showing up in ath9k, either from the guys at Atheros or the community? Also, what of TPC? (Transmit power control) -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote: On Thu, Feb 25, 2010 at 09:37:12PM -0800, Galen wrote: On Feb 24, 2010, at 4:39 PM, Luis R. Rodriguez wrote: MRC is supported on all 11n chipsets, but not for cck rates. TX beamforming is only supported on the shiny new AR93xx chipsets. TX beamforming seems to have been supported on some old legacy chipset but there is no code to support it and I wouldn't bother trying. Luis Luis - can you comment on the MRC implementation? Is this entirely invisible to ath9k, or is this implemented / supported in software? No, frankly this is the first time I read about MRC. I just poked a few guys here about MRC and got the clarification above. Right - so the MRC functionality is in the chip's DSP and entirely invisible to the software? Yes? Just being 100% clear here... And to be clear, you think the 802.11n chipsets before the AR9300 *do not* include TxBF at all? Not that it simply isn't supported by the drivers? Only a legacy (802.11g) end of life'd device had some form of Tx beamforming, but that's not even supported and its easier to just assume no chipset supports it other than the shiny new AR93xx family. Right - and as discussed, TxBF has less benefit than with 802.11n. Since then, I have looked at some Matlab simulations here and seeing that 2 antenna MRC can slightly outperform 2 antenna TxBF. ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
On Feb 26, 2010, at 9:13 AM, Daniel Halperin wrote: On Feb 26, 2010, at 8:45 AM, Luis R. Rodriguez wrote: Luis - can you comment on the MRC implementation? Is this entirely invisible to ath9k, or is this implemented / supported in software? No, frankly this is the first time I read about MRC. I just poked a few guys here about MRC and got the clarification above. I'm confused about your goals, Galen? What is it you're trying to learn about the chips? Do you want to understand the RF-level wireless processing, or don't you? The answers are much easier to intuit if one understands the underlying processing, and I don't see how your questions can return valuable information if one does not :). I understand a significant amount about the DSP and RF processing, but I'm no chip designer, nor have I any plans to be one. MRC is a receiver-side technique that is entirely performed at the RF processing layer (likely in the DSP) and as such should be opaque to the driver-level software. It involves making the copies of signals received by the different antennas coherent and adding them before doing the normal RF processing that turns the electromagnetic signals into bits. This is simply not the purpose of the software available on the host side, even in a software HAL/MAC; this functionality is likely to be in DSP ASICs on the chips themselves. I understand most of this function is probably in the DSP - but nothing documented to date had told me whether MRC was actually present. It looks like it's entirely invisible to software which is fine. The only way I envision software having anything to do with MRC would be (maybe) some software-side control of what relative power level thresholds to use to decide when MRC is worth it. If antenna A has a signal that is 20 dB (100x) stronger than antenna B, it's likely not worth combining A and B's signals (and might take extra computation/power) and instead better to just use A. Maybe the 20 dB is configurable in ath5k/9k as it is in iwlwifi. Other than that, I'd expect there to be pretty much no software mention of MRC. Dan p.s. TxBF is still helpful with multiple spatial streams. You can combine TxBF with fewer streams than (or equal) antennas, and there are (often sizable) gains. Yes - I was looking around at this with Matlab simulations. But it seems like in a lot of cases with 2x2 configurations, by the time you have MRC and STBC involved, you tend to primarily extend your range more than increase your throughput in excellent to moderate SNR situations. p.p.s. If you do want to learn more about the RF side of things and are willing to tackle an explanation written for computer scientists without a strong EE / RF signal processing background, you can check out our tutorial called 802.11 with Multiple Antennas for Dummies. It's available from ACM here (we kept the copyright, so it should be free) http://portal.acm.org/citation.cfm?id=1672308.1672313 or off my website http://www.cs.washington.edu/homes/dhalperi direct PDF link: http://www.cs.washington.edu/homes/dhalperi/pubs/mimo_for_dummies.pdf . ___ 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
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
Right - so the MRC functionality is in the chip's DSP and entirely invisible to the software? Yes? Just being 100% clear here... Beats me. I haven't dealt with MRC at all in software so I guess. And to be clear, you think the 802.11n chipsets before the AR9300 *do not* include TxBF at all? Not that it simply isn't supported by the drivers? Only a legacy (802.11g) end of life'd device had some form of Tx beamforming, but that's not even supported and its easier to just assume no chipset supports it other than the shiny new AR93xx family. Right - and as discussed, TxBF has less benefit than with 802.11n. Oh? This is a typo. But my point is that when you have 2x2:2, MRC, multiple spatial streams, etc. adding TxBF to the equation doesn't achieve the same kinds of gains for mid to high bitrate situations you see when you drop a TxBF 802.11g system into place. At least that's my understanding... I haven't actually modeled all of these variables together into a full system. Since then, I have looked at some Matlab simulations here and seeing that 2 antenna MRC can slightly outperform 2 antenna TxBF. Good to know, can you publish your results while at it. I was only playing with MRC versus TxBF in 2x2 configurations. My data isn't conclusive enough to be published and didn't look at them in combination. Mostly, I was trying to answer the question, why would they drop TxBF from 802.11n chipsets? Did we end up with a worse performing product? And the conclusion was that MRC probably equals or beats TxBF. e.g. client with MRC connected to non-TxBF AP should achieve similar to slightly better performance than a non-MRC client with a TxBF AP, resulting in significant reception gains for virtually all stations versus a non-MRC chipset. Conversely, TxBF would only help with transmit, which is usually much less data intensive than receive for most users (e.g. station mode client radios in notebooks, desktops, phones, etc.) I also suspect that MRC makes it easier to deal with cheap / crappy hardware implementations - cheap amplifiers, suboptimal antennas, etc. So if you want a fast performing chipset and have a time/dollar/power/complexity budget to meet, MRC is a better choice for most of your customers most of the time. Or at least that's my take on it. All that said, AR9003 will still be warmly welcomed. I'm not arguing that TxBF is useless, just not quite as overwhelmingly valuable as it once was. (This is highly context sensitive though, as 3x3 802.11n APs with 802.11g clients will probably see big gains, but 3x3 802.11n to 3x3 802.11n will not see as much, and at extreme range, the TxBF may also keep a very slow connection alive longer.) It's pretty hard to encapsulate all this effectively into text, and I don't know that I have the time or expertise to build out and publish extensive simulations but I hope this makes some sense. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] AR Chipset Differences
On Feb 26, 2010, at 9:23 AM, Luis R. Rodriguez wrote: On Fri, Feb 26, 2010 at 08:08:31AM -0800, Galen wrote: I'm trying to determine the differences in features of the various Atheros chipsets supported by ath9k. Please note, I have only chosen dual band parts with at least 2 spatial stream support, as the single band parts are generally subsets of the dual band parts and the 2 spatial stream parts are generally extremely value-oriented (or power oriented.) Gen 1 - AR5008: AR5416+AR5122 - 2x2 dual band, PCI AR5416+AR5133 - 3x3 dual band, PCI AR5418+AR5133 - 3x3 dual band, PCIe Gen 2 - AR9001: AR9160+AR9104 - 2x2 dual band, PCI AR9160+AR9106 - 3x3 dual band, PCI Gen 3 - AR9002: AR9220 - 2x2, dual band, PCI AR9280 - 2x2, dual band, PCIe Did I miss any 2x2 or better 802.11n radios? Yeah our AR9287 is 2x2 single band IIRC. There is also our USB 2x2 AR9170 but that uses a Zydas MAC and Atheros Radio. But hey the firmware is available as GPL and driver is upstream. There is another USB 2x2 with Atheros MAC and Atheros Radio but not yet sure of the chipset name and if it ships. Think it might somewhere. Questions: 1) What differences exist between the AR5133 and AR9106? Beats me. If the AR9106 offers 3x3 with superior performance to the AR5008, why didn't they ever offer any kind of PCIe option? Not sure, but the answer to these sort of questions is usually demand. 2) What is the advantage of the AR9002 family over the AR9001 family? Obviously, the AR9002 is a single chip solution, likely reducing cost, power and size. But is there any improvement to radio functionality or other features? Having a single chip itself yields a lot more benefits than that. Since things are closer together it also means less complexity on overall programming. You can tell where things got easier by looking at AR_SREV_9280_10_OR_LATER(ah) checks on the hardware code, I had documented some of this on phy.c. Apart from that you also get radio and baseband enhancements, fixes, tunings, etc, the usual life of generation changes of chipsets for 802.11. I can't get into specifics as that would imply giving away the actual list of differences on each of the blocks, but to be honest I only look at that stuff when needed and that doesn't happen that often. I'm sure marketing would have glanced over that and put together docs about this with what is to be shared publicly. If you have more questions you should work with our sales or marketing teams. Note, I am interested in 802.11n features supported, quality of implementation, relative effective sensitivity, pretty much everything on the radio / DSP / layer 1 angle of things. I am curious as I want to be able to make the most appropriate hardware choices, and frankly, testing these chipsets to try and figure this out isn't the best way to do this based on my experiences thus far... I recommend the single chip families, and specificaly AR9280 is a great candidate as its dual band and uses PCI-E. From a software perspective Atheros dedicates more of its own resources for testing our newer chipsets, the newer gernation 802.11n chipsets. The AR9001 didn't get formal testing but the AR9002 did. Now its AR9002, in the near future it will be AR9003 and so on. I think that AR9003 will really do a lot to unify things, as we will finally see 3x3 and a lot of new features and will put this whole discussion to rest! I can't wait for that day... And that's the way the cookie crumbles. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
On Feb 26, 2010, at 8:42 AM, Luis R. Rodriguez wrote: On Thu, Feb 25, 2010 at 08:03:57PM -0800, Galen wrote: I am aware of the AR9300 features / SST3. The AR9100 and AR9200 also contains SST Oh? I thought SST thing was the marketing name for our full solution of 3 stream for 802.11n. It is not always mentioned, but it is present in many different specifications I have seen for the AR9100 and AR9200 family of chipsets. I think there is some discussion still as to what SST is, however... Again, I thought it was just our full 3 stream stuff. I honestly don't know - but I know SST was marketed with the 3x3 AR5008 chipsets, so I assume SST3 probably is talking about the new TxBF, ML, LDPC, etc. Now we have AR9003 which is being marketed with SST3. Was there ever an SST2? I have no clue. The AR9001 and 9002 chipsets seem to also have SST, but it wasn't marketed heavily like the AR5008. I just get tired of playing mystery meat features / mystery meat marketing BS with Atheros. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
On Feb 24, 2010, at 4:33 PM, rootki...@yahoo.it wrote: On Wed, Feb 24, 2010 at 8:41 PM, Galen gal...@zinkconsulting.com wrote: On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote: On 2010-02-24 8:22 PM, Galen wrote: This is an addendum to my earlier reply. On Feb 22, 2010, at 1:09 PM, 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. I have looked over data presented on the Atheros website and as best as I can tell, the AR5008 (and other newer chipsets, I assume) support: - STBC (space-time block coding) for TX and RX - MRC (maximal ratio combining) via zero forcing algorithm - TxBF (transmit beam forming) From what you're saying, my understanding is that MRC and and TxBF are both functioning with ath9k, with STBC being the primary remaining feature. Is this correct? TxBF isn't supported by the currently available hardware, so ath9k doesn't make use of it either. I don't know about MRC, but I don't see a difference between ath9k and other Atheros drivers in that area. So yes, of those options, only STBC is missing. Atheros' data is not very clear in all cases. However, their statements lead one to believe that transmit beamforming is supported, as is MRC. It is possible that MRC is 100% hardware based (DSP-level) and invisible to the hardware. Is that what you mean when you say, I don't know about MRC ? As for transmit beamforming, here's a great example of their clear-as-mud information: http://www.atheros.com/news/xspan.html Note how they say The new 802.11n draft specification defines an array of technical elements that Atheros is uniquely qualified to deliver and list many features which I know the hardware supports - then list two I'm not sure about, MRC and TxBF. They clearly state that MRC and TxBF were implemented in chipsets dating back to 2004. However, are they in their shipping 802.11n chipsets? It's not clear. But why would they drop important features like that from a next-generation chipset? They also have this new brand for their MIMO technology - Signal Sustain technology - which nicely obfuscates what's actually happening. -Galen Now they also have SST3: http://www.atheros.com/news/AR9300.html Leveraging the Rich Array of 11n Features to Enhance Rate-over-Range Atheros’ new implementation of 11n leverages a variety of range enhancement options to ensure that the high throughput levels achieved with the 3x3 MIMO configuration are maintained across the entire WLAN link. Low Density Parity Check (LDPC) guards against packet loss at every point on the link. Maximum Likelihood Demodulation (MLD) optimizes MIMO demodulation to boost signal strength at close range. Transmit Beamforming (TxBF) focuses transmit signals to the receiver to enhance the link rate at mid-range on the link continuum. Maximal Ratio Combining (MRC) enables the receiver to optimally combine the MIMO signal paths, aligning time and phase of the signal receive to extend link reliability at longer range. It seems they don't claim such feature set in AR9200: http://www.atheros.com/news/AR9280_AR9281.html http://www.atheros.com/pt/AR9285.htm http://www.atheros.com/news/AR9220_AR9223.html so I'm a bit confused about this I am aware of the AR9300 features / SST3. The AR9100 and AR9200 also contains SST. It is not always mentioned, but it is present in many different specifications I have seen for the AR9100 and AR9200 family of chipsets. I think there is some discussion still as to what SST is, however... -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
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
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
This is an addendum to my earlier reply. On Feb 22, 2010, at 1:09 PM, 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. I have looked over data presented on the Atheros website and as best as I can tell, the AR5008 (and other newer chipsets, I assume) support: - STBC (space-time block coding) for TX and RX - MRC (maximal ratio combining) via zero forcing algorithm - TxBF (transmit beam forming) From what you're saying, my understanding is that MRC and and TxBF are both functioning with ath9k, with STBC being the primary remaining feature. Is this correct? ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
On Feb 24, 2010, at 11:33 AM, Felix Fietkau wrote: On 2010-02-24 8:22 PM, Galen wrote: This is an addendum to my earlier reply. On Feb 22, 2010, at 1:09 PM, 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. I have looked over data presented on the Atheros website and as best as I can tell, the AR5008 (and other newer chipsets, I assume) support: - STBC (space-time block coding) for TX and RX - MRC (maximal ratio combining) via zero forcing algorithm - TxBF (transmit beam forming) From what you're saying, my understanding is that MRC and and TxBF are both functioning with ath9k, with STBC being the primary remaining feature. Is this correct? TxBF isn't supported by the currently available hardware, so ath9k doesn't make use of it either. I don't know about MRC, but I don't see a difference between ath9k and other Atheros drivers in that area. So yes, of those options, only STBC is missing. Atheros' data is not very clear in all cases. However, their statements lead one to believe that transmit beamforming is supported, as is MRC. It is possible that MRC is 100% hardware based (DSP-level) and invisible to the hardware. Is that what you mean when you say, I don't know about MRC ? As for transmit beamforming, here's a great example of their clear-as-mud information: http://www.atheros.com/news/xspan.html Note how they say The new 802.11n draft specification defines an array of technical elements that Atheros is uniquely qualified to deliver and list many features which I know the hardware supports - then list two I'm not sure about, MRC and TxBF. They clearly state that MRC and TxBF were implemented in chipsets dating back to 2004. However, are they in their shipping 802.11n chipsets? It's not clear. But why would they drop important features like that from a next-generation chipset? They also have this new brand for their MIMO technology - Signal Sustain technology - which nicely obfuscates what's actually happening. -Galen ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
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
[ath9k-devel] Ath9k MIMO Performance versus Proprietary Drivers
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
