Discussion:
[ath9k-devel] Possible to set MCS Index?
Matt Tierney
2009-09-30 15:14:57 UTC
Permalink
This might be a naive question, but I was wondering if it's possible to set
the MCS index either from a high level interface or through a hack in the
ath9k code. I'd like to fix the MCS Index to 15 but I don't know where that
is set or if I can 'force' it through modifying the ath9k code in
wireless-testing. (It doesn't appear as if iw provides that sort of
functionality and it wasn't clear that I could specify a HT rate in
hostapd.conf.)

Here's my `lspci` and `iw list` output:

02:07.0 Network controller: Atheros Communications Inc. AR5416 802.11abgn
Wireless PCI Adapter (rev 01)

***@x1:~$ iw list
Wiphy phy0
Band 1:
HT capabilities: 0x104e
* 20/40 MHz operation
* SM PS disabled
* 40 MHz short GI
* max A-MSDU len 3839
* DSSS/CCK 40 MHz
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0006 (8 usec)
HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00
HT TX/RX MCS rate indexes supported:
MCS index 0
MCS index 1
MCS index 2
MCS index 3
MCS index 4
MCS index 5
MCS index 6
MCS index 7
MCS index 8
MCS index 9
MCS index 10
MCS index 11
MCS index 12
MCS index 13
MCS index 14
MCS index 15
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point

Thanks,
Matt
Luis R. Rodriguez
2009-09-30 16:48:53 UTC
Permalink
Post by Matt Tierney
This might be a naive question, but I was wondering if it's
possible to set the MCS index either from a high level interface
or through a hack in the ath9k code. I'd like to fix the MCS Index
to 15 but I don't know where that is set or if I can 'force' it
through modifying the ath9k code in wireless-testing. (It doesn't
appear as if iw provides that sort of functionality and it wasn't
clear that I could specify a HT rate in hostapd.conf.)
mac80211 rate control code is MCS rate unaware, but we do at least
let drivers pass the MCS rate for tx status reporting. ath9k
unfortunately reports back the wrong MCS rate though because
of the way ath9k rate control works... it seems correcting this
requires a rewrite of our ath9k rate control code and no one has
prioritized on that as its a non-functional fix.

The first step then is to make mac80211 rate controle code MCS
aware and adding MCS rate control support to minstrel, for example.

For ath9k it'd be nice to fix the rate control code to be able
to report the right MCS index, I really am not sure how involved
that is as I've tried to stay away from the rate control code.

A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.

Once mac80211 is MCS rate control aware the next step would be to
add a commands to set an MCS rate.

The cheesy and quick way to this for ath9k would be through
ath9k/debufs.c

Luis
John W. Linville
2009-09-30 17:23:07 UTC
Permalink
Post by Luis R. Rodriguez
A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.
ACK to the above...
--
John W. Linville Someday the world will need a hero, and you
***@tuxdriver.com might be all we have. Be ready.
Matt Tierney
2009-09-30 18:16:13 UTC
Permalink
Post by Luis R. Rodriguez
mac80211 rate control code is MCS rate unaware, but we do at least
let drivers pass the MCS rate for tx status reporting. ath9k
unfortunately reports back the wrong MCS rate though because
of the way ath9k rate control works...
Hm. I'm confused. I realize iw and the ath9k driver might be separate
entities, but it seemed like iw was corroborating ath9k debug output with my
setup. /sys/kernel/debug/ath9k/phy0/rcstat showed that one packet was
successfully sent at the maximum rate possible with MCS Index 12 (162 Mbps)
and index 12 seems to have that 1 bit flipped as the highest index in the
"HT MCS Set" I copied in my `iw list` printout; albeit, that was one packet
successfully sent compared to 1261 at 81.5 Mbps and 254 at 54 Mbps. Anyway,
I thought that the HT MCS Set indicated the correct values (as seen in the
ath9k rcstat) but I think you're saying it might not =(

Is there a way for me to capture the MCS rate info sent from the driver for
my own debugging view then? (It's not clear to me which ath9k debug bits to
set in order to get that information when I modprobe ath9k, if there is a
set that would give me that information).
Post by Luis R. Rodriguez
The first step then is to make mac80211 rate controle code MCS
aware and adding MCS rate control support to minstrel, for example.
For ath9k it'd be nice to fix the rate control code to be able
to report the right MCS index, I really am not sure how involved
that is as I've tried to stay away from the rate control code.
I see - this is messier than I anticipated... So, is what I'm trying to do
(set MCS tx rates) something that I should examine in mac80211 code or is
ath9k the place to be? (I'm not familiar with how all the pieces of ath9k,
mac80211, nl80211, cfg80211, etc fit together so that's all contributing to
my confusion...)
Post by Luis R. Rodriguez
A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.
Any suggestions on how to start thinking about this? Are there examples in
the ath9k code of making this sort of adaptation?

Once mac80211 is MCS rate control aware the next step would be to
Post by Luis R. Rodriguez
add a commands to set an MCS rate.
The cheesy and quick way to this for ath9k would be through
ath9k/debufs.c
Would this be able to actually set an MCS rate though? I thought that
debug.c was composed of 'read-only' features. If it is possible, then this
is the quick and dirty fix I'd like to use now, but otherwise I'm not sure
where to go digging in order to manipulate MCS tx rates. How would I
implement this though?

Thanks for you response - I didn't realize the pieces weren't exactly there
to make high throughput as accessible just yet but I'd like to think about
quick a solution in the code for now as well as a more sustainable approach
as this seems warranted.

Thanks =)
Matt
Luis R. Rodriguez
2009-09-30 19:04:37 UTC
Permalink
On Wed, Sep 30, 2009 at 11:16 AM, Matt Tierney
Post by Matt Tierney
Post by Luis R. Rodriguez
mac80211 rate control code is MCS rate unaware, but we do at least
let drivers pass the MCS rate for tx status reporting. ath9k
unfortunately reports back the wrong MCS rate though because
of the way ath9k rate control works...
Hm. I'm confused. I realize iw and the ath9k driver might be separate
entities, but it seemed like iw was corroborating ath9k debug output with my
setup. /sys/kernel/debug/ath9k/phy0/rcstat showed that one packet was
successfully sent at the maximum rate possible with MCS Index 12 (162 Mbps)
and index 12 seems to have that 1 bit flipped as the highest index in the
"HT MCS Set" I copied in my `iw list` printout; albeit, that was one packet
successfully sent compared to 1261 at 81.5 Mbps and 254 at 54 Mbps. Anyway,
I thought that the HT MCS Set indicated the correct values (as seen in the
ath9k rcstat) but I think you're saying it might not  =(
No, ath9k debugfs rcstat is fine. What we do not set properly for
mac80211 is the rx status bit rate for MCS rates, this means iw
station dump thing won't give you the right MCS rate.
Post by Matt Tierney
Is there a way for me to capture the MCS rate info sent from the driver for
my own debugging view then? (It's not clear to me which ath9k debug bits to
set in order to get that information when I modprobe ath9k, if there is a
set that would give me that information).
You were using the right thing for now:

http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
Post by Matt Tierney
Post by Luis R. Rodriguez
The first step then is to make mac80211 rate controle code MCS
aware and adding MCS rate control support to minstrel, for example.
For ath9k it'd be nice to fix the rate control code to be able
to report the right MCS index, I really am not sure how involved
that is as I've tried to stay away from the rate control code.
I see - this is messier than I anticipated... So, is what I'm trying to do
(set MCS tx rates) something that I should examine in mac80211 code or is
ath9k the place to be? (I'm not familiar with how all the pieces of ath9k,
mac80211, nl80211, cfg80211, etc fit together so that's all contributing to
my confusion...)
Try to work on a debugfs way to do this first. Something like:

echo 15 > /sys/kernel/debug/ath9k/phy0/mcs-rate

To set MCS 15 statically.
Post by Matt Tierney
Post by Luis R. Rodriguez
A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.
Any suggestions on how to start thinking about this? Are there examples in
the ath9k code of making this sort of adaptation?
As I said above, the easy way would be through debugfs. The nice thing
about debugfs is we can remove it at will later.
Post by Matt Tierney
Post by Luis R. Rodriguez
Once mac80211 is MCS rate control aware the next step would be to
add a commands to set an MCS rate.
The cheesy and quick way to this for ath9k would be through
ath9k/debufs.c
Would this be able to actually set an MCS rate though?
Why not?
Post by Matt Tierney
I thought that
debug.c was composed of 'read-only' features.
Nope, you can echo to wiphy file to add a new virtual wiphy for
example, or to the debug file to change the debug level on demand. Hm,
I guess no one reads documentation or we need to really work harder on
promoting our wireless wiki.
Post by Matt Tierney
If it is possible, then this
is the quick and dirty fix I'd like to use now,
Go for it.

Luis
Rakesh Kumar
2009-10-01 19:55:00 UTC
Permalink
@Matt:
I did hack the ath9k/mac80211/cfg80211 code for fixing a given HT rate and
also made some corresponding changes to iw, but like Louis has written,
since the rate control code itself is MCS unaware so what my hack does is to
simply fix it to a given valid rate_table array index for the given mode
(HT20/HT40).

Would love to share the hack with you if it is useful and also, can somebody
guide as to how to make that modification a permanent part of the driver? Is
that even required for the main driver, I am not sure?

--
Rakesh

On Wed, Sep 30, 2009 at 10:14 AM, Matt Tierney <
Post by Matt Tierney
This might be a naive question, but I was wondering if it's possible to set
the MCS index either from a high level interface or through a hack in the
ath9k code. I'd like to fix the MCS Index to 15 but I don't know where that
is set or if I can 'force' it through modifying the ath9k code in
wireless-testing. (It doesn't appear as if iw provides that sort of
functionality and it wasn't clear that I could specify a HT rate in
hostapd.conf.)
02:07.0 Network controller: Atheros Communications Inc. AR5416 802.11abgn
Wireless PCI Adapter (rev 01)
Wiphy phy0
HT capabilities: 0x104e
* 20/40 MHz operation
* SM PS disabled
* 40 MHz short GI
* max A-MSDU len 3839
* DSSS/CCK 40 MHz
HT A-MPDU factor: 0x0003 (65535 bytes)
HT A-MPDU density: 0x0006 (8 usec)
HT MCS set: ff ff 00 00 00 00 00 00 00 00 00 00 01 00 00 00
MCS index 0
MCS index 1
MCS index 2
MCS index 3
MCS index 4
MCS index 5
MCS index 6
MCS index 7
MCS index 8
MCS index 9
MCS index 10
MCS index 11
MCS index 12
MCS index 13
MCS index 14
MCS index 15
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Thanks,
Matt
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Luis R. Rodriguez
2009-10-02 21:22:09 UTC
Permalink
I did hack the ath9k/mac80211/cfg80211 code for fixing a given HT rate and also made some corresponding changes to iw, but like Louis has written, since the rate control code itself is MCS unaware so what my hack does is to simply fix it to a given valid rate_table array index for the given mode (HT20/HT40).
Would love to share the hack with you if it is useful
Just post the patches, might be good to CC the linux-wireless mailing list for this.
and also, can somebody guide as to how to make that modification a permanent part
of the driver? Is that even required for the main driver, I am not sure?
I cannot see what you have done so I canno advise. Anyway I'd probably advise you
to change whatever you have to use debugfs instead. Check out:

drivers/net/wireless/ath/ath9k/debug.c

Luis

Loading...