Questions for ath10k rate control, bandwidth, and channel sensing

[Michal Kazior]

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ł