* Disabling the third antenna of AR9380 3x3 NIC [not found] <BLU158-w185CA0272A5A3CC187AF1E876E0@phx.gbl> @ 2011-06-21 2:35 ` Fred Matthews 2011-06-21 8:55 ` [ath9k-devel] Disabling the third antenna for AR9380 in ath9k Mohammed Shafi 1 sibling, 0 replies; 10+ messages in thread From: Fred Matthews @ 2011-06-21 2:35 UTC (permalink / raw) To: inux-wireless, linux-kernel Hi all, I am installing the AR9380 NIC on laptops, but some only have two UFL connectors, and thus I was wondering if using only two of the UFL antenna ports will have any negative effect or difference than installing a 2x2 NIC (AR9280 for example which has only 2 ports anyway). Please kindly explain (with references if possible). Also for example is there anyway to disable transmission on the third UFL port (antenna) from ath9k or otherwise. Thank you all very much ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k [not found] <BLU158-w185CA0272A5A3CC187AF1E876E0@phx.gbl> 2011-06-21 2:35 ` Disabling the third antenna of AR9380 3x3 NIC Fred Matthews @ 2011-06-21 8:55 ` Mohammed Shafi [not found] ` <BLU158-w57EC92C4495F7C9645D7F187500@phx.gbl> 1 sibling, 1 reply; 10+ messages in thread From: Mohammed Shafi @ 2011-06-21 8:55 UTC (permalink / raw) To: Fred Matthews Cc: linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews <fredmm@hotmail.co.uk> wrote: > Hi all, > I am installing the AR9380 NIC on laptops, but some only have two UFL > connectors, and thus I was wondering if using only two of the UFL antenna > ports will have any negative effect or difference than installing a 2x2 NIC > (AR9280 for example which has only 2 ports anyway). Please kindly explain > with references if possible. > Also for example is there anyway to disable transmission on the third UFL > port (antenna) from ath9k or otherwise. > Thank you all very much you can change the tx/rx chainmask for 3x3 AR9380 to disable transmission on the third antenna cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask after this, ideally it should operate as 2x2 device as per Susinders comments. but if you got AR9280 please try to use that if 2 antenna is the constraint. > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > -- shafi ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <BLU158-w57EC92C4495F7C9645D7F187500@phx.gbl>]
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k [not found] ` <BLU158-w57EC92C4495F7C9645D7F187500@phx.gbl> @ 2011-06-22 13:40 ` Adrian Chadd 2011-06-22 14:57 ` Mohammed Shafi 1 sibling, 0 replies; 10+ messages in thread From: Adrian Chadd @ 2011-06-22 13:40 UTC (permalink / raw) To: Fred Matthews Cc: shafi.wireless, susinder, ath9k-devel, ath9k-devel, linux-wireless, linux-kernel Just find where in ath9k it sets the supported streams and set it to 2, not 3. Adrian On 22 June 2011 20:42, Fred Matthews <fredmm@hotmail.co.uk> wrote: > > Hi, > > I used that command to disable the third antenna, and applied it to both AP > and STA AR9380 NICs. > I then performed an IPerf test between both and then captured the statistics > from the sender, (below) . > You can see that in rc_stats (minstrel), the rate control actually > "attempts" sending on 3 stream MCSs (16-23) around 256 times each. > > Is there any way to prevent the RC from even attempting those rates, as if I > where to fully imitate an AR9280, it shouldnt attempt at those MCSs. > > Can Susinders comments also be detailed. > > Thanks in advance > > # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ > > AUTH > ASSOC > AUTHORIZED > WME > ht supported > cap: 0x11ce > HT20/HT40 > SM Power Save disabled > RX HT40 SGI > TX STBC > RX STBC 1-stream > Max AMSDU length: 7935 bytes > DSSS/CCK HT40 > ampdu factor/density: 3/6 > MCS mask: ff ff ff 00 00 00 00 00 00 00 > MCS tx params: 1 > 792 > 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff > a40 > -77 > 0 > type rate throughput ewma prob this prob this succ/attempt > success attempts > HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 > 230 > HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 > 252 > HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 > 474 > HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 > 76 > HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 > 80 > HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 > 70 > HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 > 82 > HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 > 76 > HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 > 75 > HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 > 68 > HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 > 85 > HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 > 257 > HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 > 75 > HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 > 72 > HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 > 73 > HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 > 73 > HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 > 1220 > HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 > 74 > HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 > 69 > HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 > 255 > HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 > 257 > HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 > 74 > HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 > 70 > HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 > 72 > HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 > 83 > HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 > 67803 > HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 > 67 > HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 > 312339 > HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 > 46.8 Mbits/sec 255 > HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 > 68 > HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > > Total packet count:: ideal 365056 lookaround 13702 > Average A-MPDU length: 5.4 > >> Date: Tue, 21 Jun 2011 14:25:36 +0530 >> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >> From: shafi.wireless@gmail.com >> To: fredmm@hotmail.co.uk >> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >> susinder@qca.qualcomm.com >> >> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews <fredmm@hotmail.co.uk> >> wrote: >> > Hi all, >> > I am installing the AR9380 NIC on laptops, but some only have two UFL >> > connectors, and thus I was wondering if using only two of the UFL >> > antenna >> > ports will have any negative effect or difference than installing a 2x2 >> > NIC >> > (AR9280 for example which has only 2 ports anyway). Please kindly >> > explain >> > with references if possible. >> > Also for example is there anyway to disable transmission on the third >> > UFL >> > port (antenna) from ath9k or otherwise. >> > Thank you all very much >> >> you can change the tx/rx chainmask for 3x3 AR9380 to disable >> transmission on the third antenna >> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >> >> after this, ideally it should operate as 2x2 device as per Susinders >> comments. but if you got AR9280 please try to use that if 2 antenna is >> the constraint. >> >> >> > _______________________________________________ >> > ath9k-devel mailing list >> > ath9k-devel@lists.ath9k.org >> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > >> > >> >> >> >> -- >> shafi > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k [not found] ` <BLU158-w57EC92C4495F7C9645D7F187500@phx.gbl> 2011-06-22 13:40 ` Adrian Chadd @ 2011-06-22 14:57 ` Mohammed Shafi 2011-06-23 11:56 ` Fred Matthews 1 sibling, 1 reply; 10+ messages in thread From: Mohammed Shafi @ 2011-06-22 14:57 UTC (permalink / raw) To: Fred Matthews Cc: linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder, Adrian Chadd On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: > > Hi, > > I used that command to disable the third antenna, and applied it to both AP > and STA AR9380 NICs. > I then performed an IPerf test between both and then captured the statistics > from the sender, (below) . > You can see that in rc_stats (minstrel), the rate control actually > "attempts" sending on 3 stream MCSs (16-23) around 256 times each. just a guess. as we are changing the chain mask via debugfs and there may be a chance we may not have informed the minstrel rate control which is maintained in upper layer(mac80211) and it might be taking what we have configured the chain masks while we had initialized the device and i have very little idea about ministrel rate control > > Is there any way to prevent the RC from even attempting those rates, as if I > where to fully imitate an AR9280, it shouldnt attempt at those MCSs. may be we can try with ath9k rate control, and see what happens which is within the ath9k driver and affects xmit.c and it may have been informed of the chain mask change. > > Can Susinders comments also be detailed. > > Thanks in advance > > # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ > > AUTH > ASSOC > AUTHORIZED > WME > ht supported > cap: 0x11ce > HT20/HT40 > SM Power Save disabled > RX HT40 SGI > TX STBC > RX STBC 1-stream > Max AMSDU length: 7935 bytes > DSSS/CCK HT40 > ampdu factor/density: 3/6 > MCS mask: ff ff ff 00 00 00 00 00 00 00 > MCS tx params: 1 > 792 > 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff > a40 > -77 > 0 > type rate throughput ewma prob this prob this succ/attempt > success attempts > HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 > 230 > HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 > 252 > HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 > 474 > HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 > 76 > HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 > 80 > HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 > 75 > HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 > 70 > HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 > 82 > HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 > 76 > HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 > 75 > HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 > 68 > HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 > 85 > HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 > 257 > HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 > 75 > HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 > 72 > HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 > 73 > HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 > 73 > HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 > 1220 > HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 > 74 > HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 > 69 > HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 > 255 > HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 > 257 > HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 > 74 > HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 > 70 > HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 > 72 > HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 > 83 > HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 > 67803 > HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 > 67 > HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 > 312339 > HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 > 46.8 Mbits/sec 255 > HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 > 68 > HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 > 255 > HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 > 256 > HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 > 256 > > Total packet count:: ideal 365056 lookaround 13702 > Average A-MPDU length: 5.4 > >> Date: Tue, 21 Jun 2011 14:25:36 +0530 >> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >> From: shafi.wireless@gmail.com >> To: fredmm@hotmail.co.uk >> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >> susinder@qca.qualcomm.com >> >> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews <fredmm@hotmail.co.uk> >> wrote: >> > Hi all, >> > I am installing the AR9380 NIC on laptops, but some only have two UFL >> > connectors, and thus I was wondering if using only two of the UFL >> > antenna >> > ports will have any negative effect or difference than installing a 2x2 >> > NIC >> > (AR9280 for example which has only 2 ports anyway). Please kindly >> > explain >> > with references if possible. >> > Also for example is there anyway to disable transmission on the third >> > UFL >> > port (antenna) from ath9k or otherwise. >> > Thank you all very much >> >> you can change the tx/rx chainmask for 3x3 AR9380 to disable >> transmission on the third antenna >> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >> >> after this, ideally it should operate as 2x2 device as per Susinders >> comments. but if you got AR9280 please try to use that if 2 antenna is >> the constraint. >> >> >> > _______________________________________________ >> > ath9k-devel mailing list >> > ath9k-devel@lists.ath9k.org >> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > >> > >> >> >> >> -- >> shafi > -- shafi ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-22 14:57 ` Mohammed Shafi @ 2011-06-23 11:56 ` Fred Matthews 2011-06-23 12:16 ` Mohammed Shafi 0 siblings, 1 reply; 10+ messages in thread From: Fred Matthews @ 2011-06-23 11:56 UTC (permalink / raw) To: shafi.wireless, linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder, adrian Hi, Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. Thanks in advance On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: > On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >> >> Hi, >> >> I used that command to disable the third antenna, and applied it to both AP >> and STA AR9380 NICs. >> I then performed an IPerf test between both and then captured the statistics >> from the sender, (below) . >> You can see that in rc_stats (minstrel), the rate control actually >> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. > > just a guess. as we are changing the chain mask via debugfs and there > may be a chance we may not have informed the minstrel rate control > which is maintained in upper layer(mac80211) and it might be taking > what we have configured the chain masks while we had initialized the > device and i have very little idea about ministrel rate control > >> >> Is there any way to prevent the RC from even attempting those rates, as if I >> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. > > may be we can try with ath9k rate control, and see what happens which > is within the ath9k driver and affects xmit.c and it may have been > informed of the chain mask change. > >> >> Can Susinders comments also be detailed. >> >> Thanks in advance >> >> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >> >> AUTH >> ASSOC >> AUTHORIZED >> WME >> ht supported >> cap: 0x11ce >> HT20/HT40 >> SM Power Save disabled >> RX HT40 SGI >> TX STBC >> RX STBC 1-stream >> Max AMSDU length: 7935 bytes >> DSSS/CCK HT40 >> ampdu factor/density: 3/6 >> MCS mask: ff ff ff 00 00 00 00 00 00 00 >> MCS tx params: 1 >> 792 >> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >> a40 >> -77 >> 0 >> type rate throughput ewma prob this prob this succ/attempt >> success attempts >> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >> 230 >> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >> 75 >> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >> 252 >> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >> 75 >> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >> 474 >> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >> 76 >> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >> 80 >> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >> 75 >> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >> 70 >> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >> 82 >> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >> 76 >> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >> 75 >> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >> 68 >> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >> 85 >> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >> 257 >> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >> 75 >> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >> 72 >> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >> 73 >> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >> 73 >> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >> 1220 >> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >> 74 >> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >> 69 >> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >> 255 >> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >> 257 >> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >> 74 >> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >> 255 >> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >> 70 >> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >> 72 >> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >> 83 >> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >> 67803 >> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >> 67 >> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >> 312339 >> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >> 46.8 Mbits/sec 255 >> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >> 255 >> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >> 68 >> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >> 255 >> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >> 256 >> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >> 256 >> >> Total packet count:: ideal 365056 lookaround 13702 >> Average A-MPDU length: 5.4 >> >>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>> From: shafi.wireless@gmail.com >>> To: fredmm@hotmail.co.uk >>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>> susinder@qca.qualcomm.com >>> >>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>> wrote: >>> > Hi all, >>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>> > connectors, and thus I was wondering if using only two of the UFL >>> > antenna >>> > ports will have any negative effect or difference than installing a 2x2 >>> > NIC >>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>> > explain >>> > with references if possible. >>> > Also for example is there anyway to disable transmission on the third >>> > UFL >>> > port (antenna) from ath9k or otherwise. >>> > Thank you all very much >>> >>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>> transmission on the third antenna >>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>> >>> after this, ideally it should operate as 2x2 device as per Susinders >>> comments. but if you got AR9280 please try to use that if 2 antenna is >>> the constraint. >>> >>> >>> > _______________________________________________ >>> > ath9k-devel mailing list >>> > ath9k-devel@lists.ath9k.org >>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> > >>> > >>> >>> >>> >>> -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-23 11:56 ` Fred Matthews @ 2011-06-23 12:16 ` Mohammed Shafi 2011-06-23 12:22 ` Adrian Chadd 0 siblings, 1 reply; 10+ messages in thread From: Mohammed Shafi @ 2011-06-23 12:16 UTC (permalink / raw) To: Fred Matthews Cc: linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder, adrian On Thu, Jun 23, 2011 at 5:26 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: > > > Hi, > > Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. > > Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. hi, i am not familiar with the minstrel rate control, but as you had asked I grep'd for MINSTREL_MAX_STREAMS to see if we can quickly add a debug entry to change it. but usage like this below suggests we can quickly hack the macro to 2 rather than adding a debug entry const struct mcs_group minstrel_mcs_groups[] = { MCS_GROUP(1, 0, 0), MCS_GROUP(2, 0, 0), #if MINSTREL_MAX_STREAMS >= 3 MCS_GROUP(3, 0, 0), #endif > > Thanks in advance > > > > On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: >> On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >>> >>> Hi, >>> >>> I used that command to disable the third antenna, and applied it to both AP >>> and STA AR9380 NICs. >>> I then performed an IPerf test between both and then captured the statistics >>> from the sender, (below) . >>> You can see that in rc_stats (minstrel), the rate control actually >>> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. >> >> just a guess. as we are changing the chain mask via debugfs and there >> may be a chance we may not have informed the minstrel rate control >> which is maintained in upper layer(mac80211) and it might be taking >> what we have configured the chain masks while we had initialized the >> device and i have very little idea about ministrel rate control >> >>> >>> Is there any way to prevent the RC from even attempting those rates, as if I >>> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. >> >> may be we can try with ath9k rate control, and see what happens which >> is within the ath9k driver and affects xmit.c and it may have been >> informed of the chain mask change. >> >>> >>> Can Susinders comments also be detailed. >>> >>> Thanks in advance >>> >>> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >>> >>> AUTH >>> ASSOC >>> AUTHORIZED >>> WME >>> ht supported >>> cap: 0x11ce >>> HT20/HT40 >>> SM Power Save disabled >>> RX HT40 SGI >>> TX STBC >>> RX STBC 1-stream >>> Max AMSDU length: 7935 bytes >>> DSSS/CCK HT40 >>> ampdu factor/density: 3/6 >>> MCS mask: ff ff ff 00 00 00 00 00 00 00 >>> MCS tx params: 1 >>> 792 >>> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >>> a40 >>> -77 >>> 0 >>> type rate throughput ewma prob this prob this succ/attempt >>> success attempts >>> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >>> 230 >>> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >>> 75 >>> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >>> 252 >>> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >>> 75 >>> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >>> 474 >>> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>> 76 >>> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>> 80 >>> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >>> 75 >>> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >>> 70 >>> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >>> 82 >>> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>> 76 >>> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>> 75 >>> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>> 68 >>> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>> 85 >>> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>> 257 >>> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >>> 75 >>> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >>> 72 >>> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >>> 73 >>> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >>> 73 >>> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >>> 1220 >>> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >>> 74 >>> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >>> 69 >>> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >>> 255 >>> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>> 257 >>> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>> 74 >>> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>> 255 >>> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >>> 70 >>> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >>> 72 >>> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >>> 83 >>> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >>> 67803 >>> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >>> 67 >>> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >>> 312339 >>> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >>> 46.8 Mbits/sec 255 >>> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >>> 255 >>> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >>> 68 >>> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >>> 255 >>> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >>> 256 >>> >>> Total packet count:: ideal 365056 lookaround 13702 >>> Average A-MPDU length: 5.4 >>> >>>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>>> From: shafi.wireless@gmail.com >>>> To: fredmm@hotmail.co.uk >>>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>>> susinder@qca.qualcomm.com >>>> >>>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>>> wrote: >>>> > Hi all, >>>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>>> > connectors, and thus I was wondering if using only two of the UFL >>>> > antenna >>>> > ports will have any negative effect or difference than installing a 2x2 >>>> > NIC >>>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>>> > explain >>>> > with references if possible. >>>> > Also for example is there anyway to disable transmission on the third >>>> > UFL >>>> > port (antenna) from ath9k or otherwise. >>>> > Thank you all very much >>>> >>>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>>> transmission on the third antenna >>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>>> >>>> after this, ideally it should operate as 2x2 device as per Susinders >>>> comments. but if you got AR9280 please try to use that if 2 antenna is >>>> the constraint. >>>> >>>> >>>> > _______________________________________________ >>>> > ath9k-devel mailing list >>>> > ath9k-devel@lists.ath9k.org >>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> > >>>> > >>>> >>>> >>>> >>>> -- > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- shafi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-23 12:16 ` Mohammed Shafi @ 2011-06-23 12:22 ` Adrian Chadd 2011-06-23 12:42 ` Mohammed Shafi 2011-06-23 13:40 ` Mohammed Shafi 0 siblings, 2 replies; 10+ messages in thread From: Adrian Chadd @ 2011-06-23 12:22 UTC (permalink / raw) To: Mohammed Shafi Cc: Fred Matthews, linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder As I said, there's a value in the ath9k code that gets set based on the chipset type. static void setup_ht_cap(struct ath_softc *sc, struct ieee80211_sta_ht_cap *ht_info) in init.c That should be all you need to do to communicate to the higher layers that you only support 2 streams. You're checking the wrong place. You're seeing _TX_ errors, but what you're not seeing (likely because you don't have a 3 stream peer) is that you're still advertising supporting MCS0->24, so peers may send you MCS16->24 even though you can't receive it. The correct way is to patch the driver to only enable 2 streams in the HT capability setup, so mac80211 and the rate control code only advertises MCS0-15 and TX'es MCS0-15 respectively. (You have to do this as well as disabling the third chain btw.) Adrian On 23 June 2011 20:16, Mohammed Shafi <shafi.wireless@gmail.com> wrote: > On Thu, Jun 23, 2011 at 5:26 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: >> >> >> Hi, >> >> Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. >> >> Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. > > hi, > > i am not familiar with the minstrel rate control, but as you had asked > I grep'd for MINSTREL_MAX_STREAMS to see if we can quickly add a debug > entry to change it. but usage like this below suggests we can quickly > hack the macro to 2 rather than adding a debug entry > > const struct mcs_group minstrel_mcs_groups[] = { > MCS_GROUP(1, 0, 0), > MCS_GROUP(2, 0, 0), > #if MINSTREL_MAX_STREAMS >= 3 > MCS_GROUP(3, 0, 0), > #endif > > >> >> Thanks in advance >> >> >> >> On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: >>> On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >>>> >>>> Hi, >>>> >>>> I used that command to disable the third antenna, and applied it to both AP >>>> and STA AR9380 NICs. >>>> I then performed an IPerf test between both and then captured the statistics >>>> from the sender, (below) . >>>> You can see that in rc_stats (minstrel), the rate control actually >>>> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. >>> >>> just a guess. as we are changing the chain mask via debugfs and there >>> may be a chance we may not have informed the minstrel rate control >>> which is maintained in upper layer(mac80211) and it might be taking >>> what we have configured the chain masks while we had initialized the >>> device and i have very little idea about ministrel rate control >>> >>>> >>>> Is there any way to prevent the RC from even attempting those rates, as if I >>>> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. >>> >>> may be we can try with ath9k rate control, and see what happens which >>> is within the ath9k driver and affects xmit.c and it may have been >>> informed of the chain mask change. >>> >>>> >>>> Can Susinders comments also be detailed. >>>> >>>> Thanks in advance >>>> >>>> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >>>> >>>> AUTH >>>> ASSOC >>>> AUTHORIZED >>>> WME >>>> ht supported >>>> cap: 0x11ce >>>> HT20/HT40 >>>> SM Power Save disabled >>>> RX HT40 SGI >>>> TX STBC >>>> RX STBC 1-stream >>>> Max AMSDU length: 7935 bytes >>>> DSSS/CCK HT40 >>>> ampdu factor/density: 3/6 >>>> MCS mask: ff ff ff 00 00 00 00 00 00 00 >>>> MCS tx params: 1 >>>> 792 >>>> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >>>> a40 >>>> -77 >>>> 0 >>>> type rate throughput ewma prob this prob this succ/attempt >>>> success attempts >>>> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >>>> 230 >>>> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >>>> 75 >>>> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >>>> 252 >>>> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >>>> 75 >>>> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >>>> 474 >>>> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>> 76 >>>> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>> 80 >>>> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >>>> 75 >>>> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >>>> 70 >>>> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >>>> 82 >>>> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>> 76 >>>> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>> 75 >>>> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>> 68 >>>> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>> 85 >>>> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>> 257 >>>> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >>>> 75 >>>> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >>>> 72 >>>> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >>>> 73 >>>> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >>>> 73 >>>> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >>>> 1220 >>>> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >>>> 74 >>>> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >>>> 69 >>>> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >>>> 255 >>>> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>> 257 >>>> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>> 74 >>>> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>> 255 >>>> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >>>> 70 >>>> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >>>> 72 >>>> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >>>> 83 >>>> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >>>> 67803 >>>> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >>>> 67 >>>> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >>>> 312339 >>>> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >>>> 46.8 Mbits/sec 255 >>>> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>> 255 >>>> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>> 68 >>>> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>> 255 >>>> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>> 256 >>>> >>>> Total packet count:: ideal 365056 lookaround 13702 >>>> Average A-MPDU length: 5.4 >>>> >>>>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>>>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>>>> From: shafi.wireless@gmail.com >>>>> To: fredmm@hotmail.co.uk >>>>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>>>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>>>> susinder@qca.qualcomm.com >>>>> >>>>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>>>> wrote: >>>>> > Hi all, >>>>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>>>> > connectors, and thus I was wondering if using only two of the UFL >>>>> > antenna >>>>> > ports will have any negative effect or difference than installing a 2x2 >>>>> > NIC >>>>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>>>> > explain >>>>> > with references if possible. >>>>> > Also for example is there anyway to disable transmission on the third >>>>> > UFL >>>>> > port (antenna) from ath9k or otherwise. >>>>> > Thank you all very much >>>>> >>>>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>>>> transmission on the third antenna >>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>>>> >>>>> after this, ideally it should operate as 2x2 device as per Susinders >>>>> comments. but if you got AR9280 please try to use that if 2 antenna is >>>>> the constraint. >>>>> >>>>> >>>>> > _______________________________________________ >>>>> > ath9k-devel mailing list >>>>> > ath9k-devel@lists.ath9k.org >>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> -- >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > > -- > shafi > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-23 12:22 ` Adrian Chadd @ 2011-06-23 12:42 ` Mohammed Shafi 2011-06-23 13:40 ` Mohammed Shafi 1 sibling, 0 replies; 10+ messages in thread From: Mohammed Shafi @ 2011-06-23 12:42 UTC (permalink / raw) To: Adrian Chadd Cc: Fred Matthews, linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder On Thu, Jun 23, 2011 at 5:52 PM, Adrian Chadd <adrian@freebsd.org> wrote: > As I said, there's a value in the ath9k code that gets set based on > the chipset type. > > static void setup_ht_cap(struct ath_softc *sc, > struct ieee80211_sta_ht_cap *ht_info) > > in init.c > > That should be all you need to do to communicate to the higher layers > that you only support 2 streams. Adrian thanks a lot for the pointer, should this be sufficient? or are we still missing communicating something to the upper layer, all i can see is this affects rx_mask sent to the upper layer diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index 50103b2..079359e 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -251,6 +251,10 @@ static void setup_ht_cap(struct ath_softc *sc, max_streams = 3; else max_streams = 2; + /* + * hard code max_streams + */ + max_streams = 2; if (AR_SREV_9280_20_OR_LATER(ah)) { if (max_streams >= 2) > > You're checking the wrong place. You're seeing _TX_ errors, but what > you're not seeing (likely because you don't have a 3 stream peer) is > that you're still advertising supporting MCS0->24, so peers may send > you MCS16->24 even though you can't receive it. > > The correct way is to patch the driver to only enable 2 streams in the > HT capability setup, so mac80211 and the rate control code only > advertises MCS0-15 and TX'es MCS0-15 respectively. > > (You have to do this as well as disabling the third chain btw.) > > > > Adrian > > On 23 June 2011 20:16, Mohammed Shafi <shafi.wireless@gmail.com> wrote: >> On Thu, Jun 23, 2011 at 5:26 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: >>> >>> >>> Hi, >>> >>> Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. >>> >>> Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. >> >> hi, >> >> i am not familiar with the minstrel rate control, but as you had asked >> I grep'd for MINSTREL_MAX_STREAMS to see if we can quickly add a debug >> entry to change it. but usage like this below suggests we can quickly >> hack the macro to 2 rather than adding a debug entry >> >> const struct mcs_group minstrel_mcs_groups[] = { >> MCS_GROUP(1, 0, 0), >> MCS_GROUP(2, 0, 0), >> #if MINSTREL_MAX_STREAMS >= 3 >> MCS_GROUP(3, 0, 0), >> #endif >> >> >>> >>> Thanks in advance >>> >>> >>> >>> On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: >>>> On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >>>>> >>>>> Hi, >>>>> >>>>> I used that command to disable the third antenna, and applied it to both AP >>>>> and STA AR9380 NICs. >>>>> I then performed an IPerf test between both and then captured the statistics >>>>> from the sender, (below) . >>>>> You can see that in rc_stats (minstrel), the rate control actually >>>>> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. >>>> >>>> just a guess. as we are changing the chain mask via debugfs and there >>>> may be a chance we may not have informed the minstrel rate control >>>> which is maintained in upper layer(mac80211) and it might be taking >>>> what we have configured the chain masks while we had initialized the >>>> device and i have very little idea about ministrel rate control >>>> >>>>> >>>>> Is there any way to prevent the RC from even attempting those rates, as if I >>>>> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. >>>> >>>> may be we can try with ath9k rate control, and see what happens which >>>> is within the ath9k driver and affects xmit.c and it may have been >>>> informed of the chain mask change. >>>> >>>>> >>>>> Can Susinders comments also be detailed. >>>>> >>>>> Thanks in advance >>>>> >>>>> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >>>>> >>>>> AUTH >>>>> ASSOC >>>>> AUTHORIZED >>>>> WME >>>>> ht supported >>>>> cap: 0x11ce >>>>> HT20/HT40 >>>>> SM Power Save disabled >>>>> RX HT40 SGI >>>>> TX STBC >>>>> RX STBC 1-stream >>>>> Max AMSDU length: 7935 bytes >>>>> DSSS/CCK HT40 >>>>> ampdu factor/density: 3/6 >>>>> MCS mask: ff ff ff 00 00 00 00 00 00 00 >>>>> MCS tx params: 1 >>>>> 792 >>>>> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >>>>> a40 >>>>> -77 >>>>> 0 >>>>> type rate throughput ewma prob this prob this succ/attempt >>>>> success attempts >>>>> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >>>>> 230 >>>>> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >>>>> 252 >>>>> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >>>>> 474 >>>>> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 76 >>>>> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 80 >>>>> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >>>>> 70 >>>>> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >>>>> 82 >>>>> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 76 >>>>> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 75 >>>>> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 68 >>>>> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 85 >>>>> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 257 >>>>> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >>>>> 72 >>>>> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >>>>> 73 >>>>> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >>>>> 73 >>>>> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >>>>> 1220 >>>>> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >>>>> 74 >>>>> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >>>>> 69 >>>>> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >>>>> 255 >>>>> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 257 >>>>> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 74 >>>>> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >>>>> 70 >>>>> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >>>>> 72 >>>>> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >>>>> 83 >>>>> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >>>>> 67803 >>>>> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >>>>> 67 >>>>> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >>>>> 312339 >>>>> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >>>>> 46.8 Mbits/sec 255 >>>>> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 68 >>>>> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> >>>>> Total packet count:: ideal 365056 lookaround 13702 >>>>> Average A-MPDU length: 5.4 >>>>> >>>>>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>>>>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>>>>> From: shafi.wireless@gmail.com >>>>>> To: fredmm@hotmail.co.uk >>>>>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>>>>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>>>>> susinder@qca.qualcomm.com >>>>>> >>>>>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>>>>> wrote: >>>>>> > Hi all, >>>>>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>>>>> > connectors, and thus I was wondering if using only two of the UFL >>>>>> > antenna >>>>>> > ports will have any negative effect or difference than installing a 2x2 >>>>>> > NIC >>>>>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>>>>> > explain >>>>>> > with references if possible. >>>>>> > Also for example is there anyway to disable transmission on the third >>>>>> > UFL >>>>>> > port (antenna) from ath9k or otherwise. >>>>>> > Thank you all very much >>>>>> >>>>>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>>>>> transmission on the third antenna >>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>>>>> >>>>>> after this, ideally it should operate as 2x2 device as per Susinders >>>>>> comments. but if you got AR9280 please try to use that if 2 antenna is >>>>>> the constraint. >>>>>> >>>>>> >>>>>> > _______________________________________________ >>>>>> > ath9k-devel mailing list >>>>>> > ath9k-devel@lists.ath9k.org >>>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> >> -- >> shafi >> > -- shafi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-23 12:22 ` Adrian Chadd 2011-06-23 12:42 ` Mohammed Shafi @ 2011-06-23 13:40 ` Mohammed Shafi 2011-06-23 13:56 ` Adrian Chadd 1 sibling, 1 reply; 10+ messages in thread From: Mohammed Shafi @ 2011-06-23 13:40 UTC (permalink / raw) To: Adrian Chadd, Fred Matthews Cc: linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder On Thu, Jun 23, 2011 at 5:52 PM, Adrian Chadd <adrian@freebsd.org> wrote: > As I said, there's a value in the ath9k code that gets set based on > the chipset type. > > static void setup_ht_cap(struct ath_softc *sc, > struct ieee80211_sta_ht_cap *ht_info) > > in init.c > > That should be all you need to do to communicate to the higher layers > that you only support 2 streams. rather than changing the chain mask via debugfs, the best way is to hard code them when we read the chain mask from EEPROM(with inputs from Susinder) diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c index 07827b5..b96e380 100644 --- a/drivers/net/wireless/ath/ath9k/hw.c +++ b/drivers/net/wireless/ath/ath9k/hw.c @@ -1990,6 +1990,9 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah) /* Use rx_chainmask from EEPROM. */ pCap->rx_chainmask = ah->eep_ops->get_eeprom(ah, EEP_RX_MASK); + pCap->tx_chainmask = 0x3; + pCap->rx_chainmask = 0x3; + ah->misc_mode |= AR_PCU_MIC_NEW_LOC_ENA; /* enable key search for every frame in an aggregate */ > > You're checking the wrong place. You're seeing _TX_ errors, but what > you're not seeing (likely because you don't have a 3 stream peer) is > that you're still advertising supporting MCS0->24, so peers may send > you MCS16->24 even though you can't receive it. > > The correct way is to patch the driver to only enable 2 streams in the > HT capability setup, so mac80211 and the rate control code only > advertises MCS0-15 and TX'es MCS0-15 respectively. > > (You have to do this as well as disabling the third chain btw.) > > > > Adrian > > On 23 June 2011 20:16, Mohammed Shafi <shafi.wireless@gmail.com> wrote: >> On Thu, Jun 23, 2011 at 5:26 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: >>> >>> >>> Hi, >>> >>> Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. >>> >>> Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. >> >> hi, >> >> i am not familiar with the minstrel rate control, but as you had asked >> I grep'd for MINSTREL_MAX_STREAMS to see if we can quickly add a debug >> entry to change it. but usage like this below suggests we can quickly >> hack the macro to 2 rather than adding a debug entry >> >> const struct mcs_group minstrel_mcs_groups[] = { >> MCS_GROUP(1, 0, 0), >> MCS_GROUP(2, 0, 0), >> #if MINSTREL_MAX_STREAMS >= 3 >> MCS_GROUP(3, 0, 0), >> #endif >> >> >>> >>> Thanks in advance >>> >>> >>> >>> On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: >>>> On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >>>>> >>>>> Hi, >>>>> >>>>> I used that command to disable the third antenna, and applied it to both AP >>>>> and STA AR9380 NICs. >>>>> I then performed an IPerf test between both and then captured the statistics >>>>> from the sender, (below) . >>>>> You can see that in rc_stats (minstrel), the rate control actually >>>>> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. >>>> >>>> just a guess. as we are changing the chain mask via debugfs and there >>>> may be a chance we may not have informed the minstrel rate control >>>> which is maintained in upper layer(mac80211) and it might be taking >>>> what we have configured the chain masks while we had initialized the >>>> device and i have very little idea about ministrel rate control >>>> >>>>> >>>>> Is there any way to prevent the RC from even attempting those rates, as if I >>>>> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. >>>> >>>> may be we can try with ath9k rate control, and see what happens which >>>> is within the ath9k driver and affects xmit.c and it may have been >>>> informed of the chain mask change. >>>> >>>>> >>>>> Can Susinders comments also be detailed. >>>>> >>>>> Thanks in advance >>>>> >>>>> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >>>>> >>>>> AUTH >>>>> ASSOC >>>>> AUTHORIZED >>>>> WME >>>>> ht supported >>>>> cap: 0x11ce >>>>> HT20/HT40 >>>>> SM Power Save disabled >>>>> RX HT40 SGI >>>>> TX STBC >>>>> RX STBC 1-stream >>>>> Max AMSDU length: 7935 bytes >>>>> DSSS/CCK HT40 >>>>> ampdu factor/density: 3/6 >>>>> MCS mask: ff ff ff 00 00 00 00 00 00 00 >>>>> MCS tx params: 1 >>>>> 792 >>>>> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >>>>> a40 >>>>> -77 >>>>> 0 >>>>> type rate throughput ewma prob this prob this succ/attempt >>>>> success attempts >>>>> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >>>>> 230 >>>>> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >>>>> 252 >>>>> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >>>>> 474 >>>>> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 76 >>>>> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 80 >>>>> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >>>>> 70 >>>>> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >>>>> 82 >>>>> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 76 >>>>> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 75 >>>>> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 68 >>>>> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 85 >>>>> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 257 >>>>> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >>>>> 75 >>>>> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >>>>> 72 >>>>> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >>>>> 73 >>>>> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >>>>> 73 >>>>> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >>>>> 1220 >>>>> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >>>>> 74 >>>>> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >>>>> 69 >>>>> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >>>>> 255 >>>>> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 257 >>>>> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 74 >>>>> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >>>>> 70 >>>>> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >>>>> 72 >>>>> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >>>>> 83 >>>>> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >>>>> 67803 >>>>> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >>>>> 67 >>>>> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >>>>> 312339 >>>>> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >>>>> 46.8 Mbits/sec 255 >>>>> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>> 68 >>>>> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>> 255 >>>>> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>> 256 >>>>> >>>>> Total packet count:: ideal 365056 lookaround 13702 >>>>> Average A-MPDU length: 5.4 >>>>> >>>>>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>>>>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>>>>> From: shafi.wireless@gmail.com >>>>>> To: fredmm@hotmail.co.uk >>>>>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>>>>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>>>>> susinder@qca.qualcomm.com >>>>>> >>>>>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>>>>> wrote: >>>>>> > Hi all, >>>>>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>>>>> > connectors, and thus I was wondering if using only two of the UFL >>>>>> > antenna >>>>>> > ports will have any negative effect or difference than installing a 2x2 >>>>>> > NIC >>>>>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>>>>> > explain >>>>>> > with references if possible. >>>>>> > Also for example is there anyway to disable transmission on the third >>>>>> > UFL >>>>>> > port (antenna) from ath9k or otherwise. >>>>>> > Thank you all very much >>>>>> >>>>>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>>>>> transmission on the third antenna >>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>>>>> >>>>>> after this, ideally it should operate as 2x2 device as per Susinders >>>>>> comments. but if you got AR9280 please try to use that if 2 antenna is >>>>>> the constraint. >>>>>> >>>>>> >>>>>> > _______________________________________________ >>>>>> > ath9k-devel mailing list >>>>>> > ath9k-devel@lists.ath9k.org >>>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> >> -- >> shafi >> > -- shafi ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k 2011-06-23 13:40 ` Mohammed Shafi @ 2011-06-23 13:56 ` Adrian Chadd 0 siblings, 0 replies; 10+ messages in thread From: Adrian Chadd @ 2011-06-23 13:56 UTC (permalink / raw) To: Mohammed Shafi Cc: Fred Matthews, linux-kernel, linux-wireless, ath9k-devel, ath9k-devel, susinder Ah, thanks for digging. You likely need both.. the chainmask may be used somewhere else that I'm not familiar with. But it should be limited by the max_streams, as the AR5416/AR9160 is a 3-chain device with two streams, and: /* set up supported mcs set */ memset(&ht_info->mcs, 0, sizeof(ht_info->mcs)); tx_streams = ath9k_cmn_count_streams(common->tx_chainmask, max_streams); rx_streams = ath9k_cmn_count_streams(common->rx_chainmask, max_streams); .. so for the AR5416/AR9160 case, the chainmask is 0x7, max_streams will be 2, and all the various rate control and MCS negotiation seems to cope. I think it should be enough to set the TX/RX chainmask and the max_streams value. Adrian On 23 June 2011 21:40, Mohammed Shafi <shafi.wireless@gmail.com> wrote: > On Thu, Jun 23, 2011 at 5:52 PM, Adrian Chadd <adrian@freebsd.org> wrote: >> As I said, there's a value in the ath9k code that gets set based on >> the chipset type. >> >> static void setup_ht_cap(struct ath_softc *sc, >> struct ieee80211_sta_ht_cap *ht_info) >> >> in init.c >> >> That should be all you need to do to communicate to the higher layers >> that you only support 2 streams. > > rather than changing the chain mask via debugfs, the best way is to > hard code them when we read the chain mask from EEPROM(with inputs > from Susinder) > > diff --git a/drivers/net/wireless/ath/ath9k/hw.c > b/drivers/net/wireless/ath/ath9k/hw.c > index 07827b5..b96e380 100644 > --- a/drivers/net/wireless/ath/ath9k/hw.c > +++ b/drivers/net/wireless/ath/ath9k/hw.c > @@ -1990,6 +1990,9 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah) > /* Use rx_chainmask from EEPROM. */ > pCap->rx_chainmask = ah->eep_ops->get_eeprom(ah, EEP_RX_MASK); > > + pCap->tx_chainmask = 0x3; > + pCap->rx_chainmask = 0x3; > + > ah->misc_mode |= AR_PCU_MIC_NEW_LOC_ENA; > > /* enable key search for every frame in an aggregate */ > > >> >> You're checking the wrong place. You're seeing _TX_ errors, but what >> you're not seeing (likely because you don't have a 3 stream peer) is >> that you're still advertising supporting MCS0->24, so peers may send >> you MCS16->24 even though you can't receive it. >> >> The correct way is to patch the driver to only enable 2 streams in the >> HT capability setup, so mac80211 and the rate control code only >> advertises MCS0-15 and TX'es MCS0-15 respectively. >> >> (You have to do this as well as disabling the third chain btw.) >> >> >> >> Adrian >> >> On 23 June 2011 20:16, Mohammed Shafi <shafi.wireless@gmail.com> wrote: >>> On Thu, Jun 23, 2011 at 5:26 PM, Fred Matthews <fredmm@hotmail.co.uk> wrote: >>>> >>>> >>>> Hi, >>>> >>>> Regarding streams used in Minstrel RC, I found that in "net/mac80211/rc80211_minstrel_ht.h", at line 16, there is "#define MINSTREL_MAX_STREAMS 3", that sets the number of streams for minstrel RC. >>>> >>>> Now can someone help to pass this onto debugfs, so that we can change from 3 streams to 2 streams at runtime like the rx_chainmask. I tried creating a u8 stream_number and struct dentry *dbg_stream_number in the header file, then a debugfs_create_u8 in the c file. Then used it to redefine MINSTREL_MAX_STREAMS, but when I tested this I got errors, therefore, can anyone kindly share a patch to do this correctly. >>> >>> hi, >>> >>> i am not familiar with the minstrel rate control, but as you had asked >>> I grep'd for MINSTREL_MAX_STREAMS to see if we can quickly add a debug >>> entry to change it. but usage like this below suggests we can quickly >>> hack the macro to 2 rather than adding a debug entry >>> >>> const struct mcs_group minstrel_mcs_groups[] = { >>> MCS_GROUP(1, 0, 0), >>> MCS_GROUP(2, 0, 0), >>> #if MINSTREL_MAX_STREAMS >= 3 >>> MCS_GROUP(3, 0, 0), >>> #endif >>> >>> >>>> >>>> Thanks in advance >>>> >>>> >>>> >>>> On Wed, Jun 22, 2011 at 3:57 PM, Mohammed Shafi wrote: >>>>> On Wed, Jun 22, 2011 at 6:12 PM, Fred Matthews wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I used that command to disable the third antenna, and applied it to both AP >>>>>> and STA AR9380 NICs. >>>>>> I then performed an IPerf test between both and then captured the statistics >>>>>> from the sender, (below) . >>>>>> You can see that in rc_stats (minstrel), the rate control actually >>>>>> "attempts" sending on 3 stream MCSs (16-23) around 256 times each. >>>>> >>>>> just a guess. as we are changing the chain mask via debugfs and there >>>>> may be a chance we may not have informed the minstrel rate control >>>>> which is maintained in upper layer(mac80211) and it might be taking >>>>> what we have configured the chain masks while we had initialized the >>>>> device and i have very little idea about ministrel rate control >>>>> >>>>>> >>>>>> Is there any way to prevent the RC from even attempting those rates, as if I >>>>>> where to fully imitate an AR9280, it shouldnt attempt at those MCSs. >>>>> >>>>> may be we can try with ath9k rate control, and see what happens which >>>>> is within the ath9k driver and affects xmit.c and it may have been >>>>> informed of the chain mask change. >>>>> >>>>>> >>>>>> Can Susinders comments also be detailed. >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> # cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/00\MAC/ >>>>>> >>>>>> AUTH >>>>>> ASSOC >>>>>> AUTHORIZED >>>>>> WME >>>>>> ht supported >>>>>> cap: 0x11ce >>>>>> HT20/HT40 >>>>>> SM Power Save disabled >>>>>> RX HT40 SGI >>>>>> TX STBC >>>>>> RX STBC 1-stream >>>>>> Max AMSDU length: 7935 bytes >>>>>> DSSS/CCK HT40 >>>>>> ampdu factor/density: 3/6 >>>>>> MCS mask: ff ff ff 00 00 00 00 00 00 00 >>>>>> MCS tx params: 1 >>>>>> 792 >>>>>> 150 ffff ffff ffff ffff ffff 60 ffff ffff ffff ffff ffff ffff ffff ffff ffff >>>>>> a40 >>>>>> -77 >>>>>> 0 >>>>>> type rate throughput ewma prob this prob this succ/attempt >>>>>> success attempts >>>>>> HT20/LGI MCS0 6.6 99.9 100.0 0( 0) 163 >>>>>> 230 >>>>>> HT20/LGI MCS1 13.1 100.0 100.0 0( 0) 75 >>>>>> 75 >>>>>> HT20/LGI MCS2 19.3 100.0 100.0 0( 0) 252 >>>>>> 252 >>>>>> HT20/LGI MCS3 25.4 100.0 100.0 0( 0) 75 >>>>>> 75 >>>>>> HT20/LGI MCS4 36.2 97.5 100.0 0( 0) 413 >>>>>> 474 >>>>>> HT20/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>>> 76 >>>>>> HT20/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>>> 80 >>>>>> HT20/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS8 13.1 100.0 100.0 0( 0) 75 >>>>>> 75 >>>>>> HT20/LGI MCS9 25.4 100.0 100.0 0( 0) 70 >>>>>> 70 >>>>>> HT20/LGI MCS10 34.2 92.2 100.0 0( 0) 79 >>>>>> 82 >>>>>> HT20/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>>> 76 >>>>>> HT20/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>>> 75 >>>>>> HT20/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>>> 68 >>>>>> HT20/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>>> 85 >>>>>> HT20/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>>> 257 >>>>>> HT20/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT20/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS0 13.6 100.0 100.0 0( 0) 75 >>>>>> 75 >>>>>> HT40/LGI MCS1 26.5 100.0 100.0 0( 0) 72 >>>>>> 72 >>>>>> HT40/LGI MCS2 38.3 100.0 100.0 0( 0) 73 >>>>>> 73 >>>>>> HT40/LGI MCS3 49.7 99.9 100.0 0( 0) 70 >>>>>> 73 >>>>>> HT40/LGI MCS4 0.0 0.0 0.0 0( 0) 10 >>>>>> 1220 >>>>>> HT40/LGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS8 26.2 98.9 100.0 0( 0) 73 >>>>>> 74 >>>>>> HT40/LGI MCS9 49.3 99.2 100.0 0( 0) 67 >>>>>> 69 >>>>>> HT40/LGI MCS10 20.5 28.9 0.0 0( 0) 14 >>>>>> 255 >>>>>> HT40/LGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>>> 257 >>>>>> HT40/LGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>>> 74 >>>>>> HT40/LGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>>> 255 >>>>>> HT40/LGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/LGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS0 15.1 100.0 100.0 0( 0) 70 >>>>>> 70 >>>>>> HT40/SGI MCS1 29.2 100.0 100.0 0( 0) 72 >>>>>> 72 >>>>>> HT40/SGI t MCS2 38.5 91.3 100.0 0( 0) 81 >>>>>> 83 >>>>>> HT40/SGI PMCS3 54.3 99.5 100.0 0( 0) 66536 >>>>>> 67803 >>>>>> HT40/SGI MCS4 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS5 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS6 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS7 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS8 29.2 100.0 100.0 0( 0) 67 >>>>>> 67 >>>>>> HT40/SGI T MCS9 54.6 99.9 100.0 0( 0) 310227 >>>>>> 312339 >>>>>> HT40/SGI MCS10 22.7 29.3 100.0 0( 0) 14 >>>>>> 46.8 Mbits/sec 255 >>>>>> HT40/SGI MCS11 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS12 0.0 0.0 0.0 0( 0) 0 >>>>>> 255 >>>>>> HT40/SGI MCS13 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS14 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS15 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS16 0.0 0.0 0.0 0( 0) 0 >>>>>> 68 >>>>>> HT40/SGI MCS17 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS18 0.0 0.0 0.0 0( 0) 0 >>>>>> 255 >>>>>> HT40/SGI MCS19 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS20 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS21 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS22 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> HT40/SGI MCS23 0.0 0.0 0.0 0( 0) 0 >>>>>> 256 >>>>>> >>>>>> Total packet count:: ideal 365056 lookaround 13702 >>>>>> Average A-MPDU length: 5.4 >>>>>> >>>>>>> Date: Tue, 21 Jun 2011 14:25:36 +0530 >>>>>>> Subject: Re: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k >>>>>>> From: shafi.wireless@gmail.com >>>>>>> To: fredmm@hotmail.co.uk >>>>>>> CC: linux-kernel@vger.kernel.org; linux-wireless@vger.kernel.org; >>>>>>> ath9k-devel@venema.h4ckr.net; ath9k-devel@lists.ath9k.org; >>>>>>> susinder@qca.qualcomm.com >>>>>>> >>>>>>> On Tue, Jun 21, 2011 at 2:07 AM, Fred Matthews >>>>>>> wrote: >>>>>>> > Hi all, >>>>>>> > I am installing the AR9380 NIC on laptops, but some only have two UFL >>>>>>> > connectors, and thus I was wondering if using only two of the UFL >>>>>>> > antenna >>>>>>> > ports will have any negative effect or difference than installing a 2x2 >>>>>>> > NIC >>>>>>> > (AR9280 for example which has only 2 ports anyway). Please kindly >>>>>>> > explain >>>>>>> > with references if possible. >>>>>>> > Also for example is there anyway to disable transmission on the third >>>>>>> > UFL >>>>>>> > port (antenna) from ath9k or otherwise. >>>>>>> > Thank you all very much >>>>>>> >>>>>>> you can change the tx/rx chainmask for 3x3 AR9380 to disable >>>>>>> transmission on the third antenna >>>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > tx_chainmask >>>>>>> cd /sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x3 > rx_chainmask >>>>>>> >>>>>>> after this, ideally it should operate as 2x2 device as per Susinders >>>>>>> comments. but if you got AR9280 please try to use that if 2 antenna is >>>>>>> the constraint. >>>>>>> >>>>>>> >>>>>>> > _______________________________________________ >>>>>>> > ath9k-devel mailing list >>>>>>> > ath9k-devel@lists.ath9k.org >>>>>>> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> >>> >>> -- >>> shafi >>> >> > > > > -- > shafi > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-06-23 13:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <BLU158-w185CA0272A5A3CC187AF1E876E0@phx.gbl>
2011-06-21 2:35 ` Disabling the third antenna of AR9380 3x3 NIC Fred Matthews
2011-06-21 8:55 ` [ath9k-devel] Disabling the third antenna for AR9380 in ath9k Mohammed Shafi
[not found] ` <BLU158-w57EC92C4495F7C9645D7F187500@phx.gbl>
2011-06-22 13:40 ` Adrian Chadd
2011-06-22 14:57 ` Mohammed Shafi
2011-06-23 11:56 ` Fred Matthews
2011-06-23 12:16 ` Mohammed Shafi
2011-06-23 12:22 ` Adrian Chadd
2011-06-23 12:42 ` Mohammed Shafi
2011-06-23 13:40 ` Mohammed Shafi
2011-06-23 13:56 ` Adrian Chadd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®