Questions for ath10k rate control, bandwidth, and channel sensing

[Changmok Yang]

Hi. Thanks for answers.
We have another question for ath10k.

Since it looks difficult to get channel sensing parameters in ath10k,
we alternatively want to use A-MPDU loss pattern.
For that, is it possible to get BlockAck information (or other
information related to sending A-MPDU) in ath10k at device driver
level?
We know it is possible in ath9k, but we have no sure for ath10k.

Thank you.
Sincerely yours,
Changmok Yang.

2016-08-29 15:48 GMT+09:00 Michal Kazior <michal.kazior at tieto.com>:
> On 26 August 2016 at 11:00, Changmok Yang <cmyang at mwnl.snu.ac.kr> wrote:
>> Hi.
>> We are trying to change transmission bandwidth and data rate.
>>
>> 1. We found that we can only control per-station channel width, and
>> rate control, like Minstrel, is not controlled by ath10k and in
>> firmware. Then, can ath10k select the transmission data rate manually?
>> If so, how? We cannot find the part the data rate is determined.
>
> It's possible to re-program given station's ratemask or you can force
> a global tx rate. See set_bitrate_mask implementation in ath10k for
> details.
>
>
>> 2. Is it possible to change operating bandwidth per station while
>> maintaining association?
>
> Yes, either via wmi_peer_assoc command or via set_peer_param command
> and one of peer_param attributes (chwidth). This stuff is mostly
> upper-cased as far as naming is concerned.
>
>
>> 3. We also want to use parameters related to channel sensing. Although
>> we found that CCA related parameters are in firmware, we alternatively
>> want to use parameters related to Ethtool in survey_info structure (in
>> include/net/cfg80211.h, the structure below). However, when we read
>> this variable in the log after Ethtrool running, the value does not
>> seem to reflect channel sensing. Where and how can we use channel
>> sensing parameters in ath10k? Is it possible?
>
> CCA thresholds would need to be overwritten by ath10k after each hw
> reset / channel change I think. You could probably look at the
> coverage_class work Benjamin and Sebastian have been doing recently as
> you'd need to do something similar.
>
> As for survey: some recent firmware builds supposedly have a on-bss
> 64-bit survey events. Not sure about the details though.
>
> Actual cycle counters used to generate/maintain survey data can be
> found at wlan_mac_base (0x20000) + same offsets as ath9k. FWIW You can
> even read them from userspace via /dev/mem + mmap() (it'll be a bit
> racy though; freezing mib counters is not a good idea with firmware
> running concurrently).
>
>
> Michał