On 03/16/2012 09:36 AM, Felix Fietkau wrote:
On 2012-03-16 5:23 PM, Ben Greear wrote:
On 03/16/2012 08:06 AM, Felix Fietkau wrote:
My personal goal is to give my users a better insight into their
wireless environment. I would like to be able to break out the
various low-level errors (as well as add them together to present
summary errors).
For anyone reporting mysterious bugs on mailing lists and such, I'd like
to ask them to dump the stats and send it to me/list/whatever.
I am still of the mind that looking for patterns in various
counters might point to underlying problems, so anything that
makes it easier to get that data is a win in my mind.
That's what debugfs is for, and it's not exactly hard to use.
I think it would be bad if tools started depending on the counters in
their current state, they're pretty messy.
With a bit of work, we could make the ethtool stats
available when debugfs is compiled out, which might give
you actual space savings and still allow at least much of
the stats. Either way, the ability to programatically
parse the ethtool stats is a big win for my use, at least.
If there are some stats that really don't work, maybe I
will notice, or maybe someone else will and we can fix
them. If you are aware of any specific ones that don't
work right, please let me know and I'll at least add some
comments to the code to mention they are questionable,
or fix them if I'm able.
There's lots of confusion in the AMPDU/Aggregates counters (some count
whole A-MPDUs, some count subframes).
That sounds fixable, if it's a problem at all.
Also, many of these counters are useless unless you're doing live
debugging and actually know what you're doing - especially the ones that
display the current queue state.
I tried to skip all of those current-queue-state counters, but I
will double-check.
Most of the PHY error counters aren't even tracked by the hw, nothing in
the driver enables their use.
Well, any reason we cannot enable those?
For some of these counters it might make sense to track them in
mac80211, as they're sufficiently generic.
That sounds nice. Maybe add a 'get_stats' object to the driver
api? If you have a list of what you want to be made
generic I'll make a try at implementing it.
Thanks,
Ben
--
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
