At most, I might can help with issues you see with CT 10.1 firmware
and CT ath10k driver.
In case it helps, we get these counters via ethtool and it appears
to be mostly accurate last time we did detailed testing.
Thanks,
Ben
On 09/08/2016 05:00 AM, Sergey Naumov wrote:
Hi All.
I've just tried ath10k from compat-wireless-2016-01-10 (OpenWRT Chaos
Calmer 15.05.1).
For ath10k from older compat-wireless packages I made a patch that
periodically updates survey stats by calling
ath10k_wmi_request_stats(ar, WMI_REQUEST_PEER_STAT)
to get low-level pdev ath10k_target_stats and then convert them to
survey stats in
ath10k_debug_read_target_stats().
This way I had the following output:
root@OpenWrt:/# iw dev wlan0 survey dump
Survey data from wlan0
frequency: 5180 MHz [in use]
noise: -103 dBm
channel active time: 1858553 ms <- These
stats grow on each call
channel busy time: 1164399 ms <-
channel receive time: 665672 ms <-
channel transmit time: 3784 ms <-
Survey data from wlan0
frequency: 5200 MHz
...
Stats I've managed to get this way were quite accurate and correspond
with reality.
In ath10k from compat-wireless-2016-01-10 I see that there was an
attempt to add survey info, but using wmi_chain_info_event stats
instead of pdev.
So the question is:
1. Why it was decided to use wmi_chain_info_event stats? After all,
unlike wmi_pdev_stats_base, they don't have tx_frame_count and
rx_frame_count, so channel receive and transmit time couldn't be
populated.
2. Why it doesn't work? =) In OpenWRT 15.15.1 for QCA9880-BR4A I get:
root@OpenWrt:/# iw dev wlan0 survey dump
Survey data from wlan0
frequency: 5180 MHz [in use]
noise: -102 dBm
channel active time: 146 ms <- These
stats never get updated
channel busy time: 60 ms <-
Survey data from wlan0
frequency: 5200 MHz
noise: -102 dBm
channel active time: 146 ms
channel busy time: 68 ms
Survey data from wlan0
frequency: 5220 MHz
...
Thanks,
Sergey.
2015-06-12 23:34 GMT+03:00 Ben Greear <[email protected]>:
On 06/12/2015 10:51 AM, Sergey Naumov wrote:
TP-link Archer C7 5GHz chip is QCA9880-BR4A.
Barrier Breaker compat-wireless package is 2014-05-22 with ath10k
firmware 38eeda3ae6f90fde5546bdd48ee4ff3090f238c0 (rx clear sometimes
is less than rx frame)
Chaos Calmer compat-wireless package is 2015-03-09 with ath10k
firmware da0f85d924226ee30c46e037120621c9e192b39e (fw_stats aren't
retrievable)
I do not think that the issue I reported is linked to buggy
wraparound, because "RX frame count" from pdev stats is increasing
faster than "RX clear count".
For example here are stats from 2 consecutive calls of "cat
/sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats":
Cycle count diff = 4251412543 - 3864224417 = 387188126
RX clear count diff = 633835870 - 574177256 = 59658614
RX frame count diff = 674834640 - 611992703 = 62841937
TX frame count diff = 14373772 - 12746248 = 1627524
RX frame diff - RX clear diff = 62841937 - 59658614 = 3183323.
I thought that RX clear counter has to always be greater than RX frame
counter, because in theory RX clear (busy) = RX frame + TX frame +
non-wifi interference. And I checked that both TX frame and ACI are
accounted in RX clear and not in RX frame, so I don't understand why
RX frame is greater.
Results presented above are measured with no clients connected to AP.
BTW what I'm trying to do is to make a survey report for ath10k work
in the same way as it works for ath9k, where CCA stats are constantly
updated for the current channel, and I also end up with discarding of
stats if overflow of cycle count occurs. So I just poll for these
stats every 50ms, compute differencies and accumulate them in survey
report if diff is positive for cycle stats.
When the cycle count overflows, you also have to take new basline for the other
counters since they will have been shifted right by 1 bit (ie, divided by 2)
whenever the cycle counter overflowed.
I have only been paying attention to the cycle and 'clear' counters,
if there is weirdness in the others I would not have noticed it.
Thanks,
Ben
Thanks,
Sergey.
2015-06-12 6:43 GMT-07:00 Ben Greear <[email protected]>:
On 06/12/2015 12:16 AM, Michal Kazior wrote:
On 11 June 2015 at 23:49, Sergey Naumov <[email protected]> wrote:
Hi all.
I'm using barrier breaker OpenWRT on TP-link Archer C7 v2.0 router and
looking at /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats content.
As far as I understand "RX frame" accounts just rx of our and all the
other APs on the same channel, while "RX clear" also accounts tx of
our AP and non-wifi interference.
At least it is true for ath9k with 2.4GHz chip on the same router,
where "channel busy time" from survey report is always greater than
"channel receive time".
But for ath10k I see that with absense of the traffic to/from our AP,
"RX frame" register value is always increased a little bit more than a
value of "RX clear" register, and it is strange.
Do you know what could be a reason?
What is the interval you're polling the values at? There's a buggy 24
second wraparound on these cycle count related stats. Maybe you're
hitting that..
Here is a link to my previous email on the wrapping issue..it is not *just*
a matter of polling more often:
https://www.marc.info/?l=linux-wireless&m=143353920909147&w=2
After dealing with this, I see expected results when using 10.1.467 based
firmware (both CT and stock).
I am using WLE900VX NIC, my 4.0.4+ kernel.
Thanks,
Ben
Another idea/guess is that firmware doesn't read these values
atomically (I recall ath9k locks CC values via control register before
reading them) and it ends up with inconsistent results.
P.S. I tried new Chaos Calmer RC1 OpenWRT release with updated ath10k
driver and binary firmware and there these low-level stats are
unavaiable (file /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats
exists but read returns error).
The firmware stats interface has a very clunky and unstable ABI. It's
broken often by firmware updates and remains so until someone
notices..
Can you provide more details, please:
- which revision of CC you're using,
- what ath10k firmware version is used,
- what compat package version ath10k is from.
Michał
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/ath10k
