* 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
* 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 related [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 related [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;
as well as URLs for NNTP newsgroup(s).