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@xxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
