* ath10k fw_stats rx_frame/rx_clear counters @ 2015-06-11 21:49 Sergey Naumov 2015-06-12 7:16 ` Michal Kazior 0 siblings, 1 reply; 8+ messages in thread From: Sergey Naumov @ 2015-06-11 21:49 UTC (permalink / raw) To: ath10k 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? 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). Thanks in advance, Sergey. _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-11 21:49 ath10k fw_stats rx_frame/rx_clear counters Sergey Naumov @ 2015-06-12 7:16 ` Michal Kazior 2015-06-12 13:43 ` Ben Greear 0 siblings, 1 reply; 8+ messages in thread From: Michal Kazior @ 2015-06-12 7:16 UTC (permalink / raw) To: Sergey Naumov; +Cc: ath10k On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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.. 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 ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-12 7:16 ` Michal Kazior @ 2015-06-12 13:43 ` Ben Greear 2015-06-12 17:51 ` Sergey Naumov 0 siblings, 1 reply; 8+ messages in thread From: Ben Greear @ 2015-06-12 13:43 UTC (permalink / raw) To: Michal Kazior, Sergey Naumov; +Cc: ath10k On 06/12/2015 12:16 AM, Michal Kazior wrote: > On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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 > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-12 13:43 ` Ben Greear @ 2015-06-12 17:51 ` Sergey Naumov 2015-06-12 18:15 ` Adrian Chadd 2015-06-12 20:34 ` Ben Greear 0 siblings, 2 replies; 8+ messages in thread From: Sergey Naumov @ 2015-06-12 17:51 UTC (permalink / raw) To: Ben Greear; +Cc: Michal Kazior, ath10k 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. Thanks, Sergey. 2015-06-12 6:43 GMT-07:00 Ben Greear <greearb@candelatech.com>: > > > On 06/12/2015 12:16 AM, Michal Kazior wrote: >> >> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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 >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-12 17:51 ` Sergey Naumov @ 2015-06-12 18:15 ` Adrian Chadd 2015-06-12 20:34 ` Ben Greear 1 sibling, 0 replies; 8+ messages in thread From: Adrian Chadd @ 2015-06-12 18:15 UTC (permalink / raw) To: Sergey Naumov; +Cc: Ben Greear, Michal Kazior, ath10k I'll go see if I can dig up how this works on the 11ac NICs. I have a sneaking suspicion that the ext20, ext40, ext80 channel bits are making things different. -a _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-12 17:51 ` Sergey Naumov 2015-06-12 18:15 ` Adrian Chadd @ 2015-06-12 20:34 ` Ben Greear 2016-09-08 12:00 ` Sergey Naumov 1 sibling, 1 reply; 8+ messages in thread From: Ben Greear @ 2015-06-12 20:34 UTC (permalink / raw) To: Sergey Naumov; +Cc: Michal Kazior, ath10k 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 <greearb@candelatech.com>: >> >> >> On 06/12/2015 12:16 AM, Michal Kazior wrote: >>> >>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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 >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com > > _______________________________________________ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2015-06-12 20:34 ` Ben Greear @ 2016-09-08 12:00 ` Sergey Naumov 2016-09-08 18:15 ` Ben Greear 0 siblings, 1 reply; 8+ messages in thread From: Sergey Naumov @ 2016-09-08 12:00 UTC (permalink / raw) To: Ben Greear; +Cc: Michal Kazior, ath10k 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 <greearb@candelatech.com>: > 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 <greearb@candelatech.com>: >>> >>> >>> On 06/12/2015 12:16 AM, Michal Kazior wrote: >>>> >>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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 >>>> ath10k@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>> >>> >>> -- >>> Ben Greear <greearb@candelatech.com> >>> Candela Technologies Inc http://www.candelatech.com >> >> _______________________________________________ >> ath10k mailing list >> ath10k@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/ath10k >> > > > -- > Ben Greear <greearb@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ath10k fw_stats rx_frame/rx_clear counters 2016-09-08 12:00 ` Sergey Naumov @ 2016-09-08 18:15 ` Ben Greear 0 siblings, 0 replies; 8+ messages in thread From: Ben Greear @ 2016-09-08 18:15 UTC (permalink / raw) To: Sergey Naumov; +Cc: Michal Kazior, ath10k 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 <greearb@candelatech.com>: >> 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 <greearb@candelatech.com>: >>>> >>>> >>>> On 06/12/2015 12:16 AM, Michal Kazior wrote: >>>>> >>>>> On 11 June 2015 at 23:49, Sergey Naumov <sknaumov@gmail.com> 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 >>>>> ath10k@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/ath10k >>>>> >>>> >>>> -- >>>> Ben Greear <greearb@candelatech.com> >>>> Candela Technologies Inc http://www.candelatech.com >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> -- >> Ben Greear <greearb@candelatech.com> >> Candela Technologies Inc http://www.candelatech.com >> > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-09-08 18:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-11 21:49 ath10k fw_stats rx_frame/rx_clear counters Sergey Naumov 2015-06-12 7:16 ` Michal Kazior 2015-06-12 13:43 ` Ben Greear 2015-06-12 17:51 ` Sergey Naumov 2015-06-12 18:15 ` Adrian Chadd 2015-06-12 20:34 ` Ben Greear 2016-09-08 12:00 ` Sergey Naumov 2016-09-08 18:15 ` Ben Greear
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.