From: Fred Matthews <fredmm@hotmail.co.uk>
To: <shafi.wireless@gmail.com>, <linux-kernel@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, <ath9k-devel@venema.h4ckr.net>,
<ath9k-devel@venema.h4ckr.net>, <susinder@qca.qualcomm.com>,
<adrian@freebsd.org>
Subject: RE: [ath9k-devel] Disabling the third antenna for AR9380 in ath9k
Date: Thu, 23 Jun 2011 12:56:36 +0100 [thread overview]
Message-ID: <BLU158-w370CB20409B2C48E8D14C887530@phx.gbl> (raw)
In-Reply-To: <BANLkTinubW6Pq7NHrpeG2pLf8SC3xLFdGg@mail.gmail.com>
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
>>> >
>>> >
>>>
>>>
>>>
>>> --
next prev parent reply other threads:[~2011-06-23 11:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU158-w370CB20409B2C48E8D14C887530@phx.gbl \
--to=fredmm@hotmail.co.uk \
--cc=adrian@freebsd.org \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=shafi.wireless@gmail.com \
--cc=susinder@qca.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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®