On 2012-03-16 5:51 PM, Ben Greear wrote: > 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. I'm OK with exporting some stats in a way that can be easily parsed, but it should be limited to data that actually makes sense and isn't available through normal API. >>> 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. Yeah, seems like I misread something there. >> 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? The hardware has a limited number of counter registers available for tracking PHY errors. Enabling PHY errors to be reported via DMA wastes tons of precious CPU cycles. >> 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. I don't have a list. - Felix -- 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
