Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets

[Ben Greear <greearb@candelatech.com>]

On 04/28/2013 08:08 AM, Felix Fietkau wrote:
> On 2013-04-28 4:54 PM, Ben Greear wrote:
>> On 04/28/2013 05:51 AM, Felix Fietkau wrote:
>>> On 2013-04-27 5:25 PM, Oleksij Rempel wrote:
>>>> Collect statistics about recived duplicate and STBC packets.
>>>> This information should help see if STBC is actually working.
>>>>
>>>> Tested on ar9285;
>>>>
>>>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>>> I thought about this patch some more, and I'm wondering what's the point
>>> in doing this? These statistics are going to be completely useless for
>>> most people and they'll waste some memory/cpu cycles, especially on
>>> small-cache devices. I think it's much more useful to simply pass the
>>> information to mac80211 via rx flags and get them added to the radiotap
>>> header.
>>> I'd like to keep the number of 'poor man's debug hacks' in the driver to
>>> a minimum, and there are some other things that I think should be
>>> removed: rx_frags and rx_beacons in struct ath_rx_stats, the tx/rx MAC
>>> sampling hack, and pretty much anything else that can be just as easily
>>> accessed from mac80211 through regular interfaces.
>>
>> Does that mean we can just put the stats in mac80211, or do we have
>> to be running a sniffer to gather the stats?
> Right now you'd have to use a sniffer, but if you really care about
> getting specific stats it might make sense to write a kernel module that
> attaches to a monitor interface and gathers them (maybe even with
> support for gathering arbitrary stats by attaching bpf filters).

I'd like ongoing stats w/out a monitor interface or sniffer, though
it would be fine to add it to the sniffer path as well.  Maybe we can
have compile-time flag to enable the extra and mostly useless
stats so only the 1% that cares pays the overhead.

> The problem I have with the current stats is they're just an arbitrary
> collection of random stuff that is probably useless for 99% of all
> users. In many cases the way the stats are collected also makes the data
> completely meaningless (e.g. because the source/destination address is
> not taken into account).
>
> Why care about the number of packets on the air that were sent with a
> specific rate flag? Why care about the number of beacons on the air
> (with no filter on a set of APs or anything)? Or what about the number
> of fragments received? To me it just looks like an incoherent set of
> useless facts.

I think having lots of stats allows for the possibility of seeing a pattern
that might otherwise be missed, and when testing in an isolated environment,
you don't have to care about who is sending what being reported..you already
know.

One thing I'd like to do, for instance, is to figure out how to get some
average MPDU lengths calculated in hopes that would correlate with decreased
performance in cases were we have lots of stations....

Thanks,
Ben

>
> - Felix
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com