Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Felix Fietkau wrote: 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. Yes, having per-station statistics would be useful, mainly for RX and TX. Right now, all the counters are global and there is no way to find out how a particular station is performing, especially in AP mode. Since mac80211 gives us proper debugfs hooks for station addition/deletion, relevant stuff can be moved there. The 'recv' file used to be just for HW errors (DESC, CRC etc.), now it has various counters that should probably be node-specific. The 'xmit' file can be trimmed and information can be maintained per-station. This will be really useful in AP mode - especially for diagnosing aggregation, QoS, PS etc. Other than these two files, the rest are simple. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
On 8 May 2013 09:07, Ben Greear gree...@candelatech.com wrote: I think it's good to keep global counters too..otherwise it is going to be a lot of work to gather per NIC stats, and since you would have to read for each station, your stats might not be quite as atomic as they used to be. But, I'm fine with adding per-station counters on top of the global stats. As a reference point, one of my in-progress hacks in FreeBSD is to add some macros to the ath(4) driver to keep per-state and global stats, using the same sample pointers. So, a macro would look like this: ATH_STAT_INC(sc, ath_node, stat_name, 1); * if I've enabled global stat counting, the sc-sc_stats.sc_stat_name stat would be bumped. * if I've enabled node stat counting, the ath_node-an_stats.an_stat_name would be bumped. I have similar ideas with net80211 - right now there's some per-node stats, but lots of stats are per-VAP. I'm going to do the same thing - take the vap and the node as part of the stat macro, and bump the per-node and per-VAP stats. Again, leaving it as a build-time option. I've found both global device / VAP stats _and_ per-node stats equally useful for debugging. They're good for debugging different sets of issues - I use the global stats for figuring out what is breaking things, and I use the per-node stats to try and understand how the AP is viewing a particular station, separate from all the other stations currently chatting. Stats are hard. Let's go shopping. :-) Adrian Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
On 04/28/2013 05:03 PM, Oleksij Rempel wrote: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: 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 li...@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. Sure. I see Wojciech Dubowik sanded some patches, for at least one year, to make exactly what Felix suggested. Are there any reason why this patches was not accepted? Wojciech if you alive and have some time, can you update them? Sure. I will try to update them based on suggested radiotap field structure for STBC and Ness. On the other hand as Felix already mentioned it's yet another line of code one needs once in a lifetime. If one is checking whether stbc is working the easiest way is to create own debugging namespace in radiotap and dump all descriptor registers there. It probably doesn't go mainline but you could apply the patches when you need and they mostly rebase cleanly. At least that's what I do. Wojtek ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 29.04.2013 08:45, schrieb Wojciech Dubowik: On 04/28/2013 05:03 PM, Oleksij Rempel wrote: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: 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 li...@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. Sure. I see Wojciech Dubowik sanded some patches, for at least one year, to make exactly what Felix suggested. Are there any reason why this patches was not accepted? Wojciech if you alive and have some time, can you update them? Sure. I will try to update them based on suggested radiotap field structure for STBC and Ness. On the other hand as Felix already mentioned it's yet another line of code one needs once in a lifetime. If one is checking whether stbc is working the easiest way is to create own debugging namespace in radiotap and dump all descriptor registers there. It probably doesn't go mainline but you could apply the patches when you need and they mostly rebase cleanly. At least that's what I do. Felix, will this patches go upstream if i make it raditap compatible? If yes, and performance and cache usage is an issue, it think we should remove this double flags mapping in ath9k. Currently we convert device specific flags to driver flags, and then convert them to mac80211 flags. There is lots of useless checks and conversations for each packet. Should i change it? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
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 li...@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. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 28.04.2013 14:51, schrieb Felix Fietkau: 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 li...@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. Sure. I'd like to keep the number of 'poor man's debug hacks' in the driver to a minimum, well, i'll prefer it to call with my name: lazy man's hack ;) 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. I think there is more things to do in ath9k. Create the list and we can talk about it. For example one of it: I needed some time to understand how some parts of code relate to the hardware. Especially Rx and Tx descriptors. Some comments in header will help... I can add some of them (may be it will help other beginners), but i afraid that i spend time but my patches wont be included. -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
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 li...@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? Thanks, Ben - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Ben Greear gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
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 li...@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). 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. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
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 li...@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 gree...@candelatech.com Candela Technologies Inc http://www.candelatech.com ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
On 2013-04-28 5:15 PM, Ben Greear wrote: 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 li...@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. I'd like to have proper justification for stats added to the code and kick out stuff not worth keeping. It's not just about runtime overhead, but keeping the number of lines of code down is important for maintenance as well. Adding extra compile time flags just makes the maintenance part worse. 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. The stats I pointed out seem mostly useless for that purpose. When testing in an isolated environment you might as well run a capture on a monitor mode interface and do some more sophisticated analysis afterwards. 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 Please don't throw hooks for such stacks all over the ath9k or mac80211 data path. Making a module for analyzing such stuff on a monitor mode interface might be a bit more work than spraying hacks onto the code, but at least it doesn't push the maintenance/performance overhead burden onto everybody else. Something like a BPF based statistics gathering module would be useful for more people as well - I'd probably help with the code myself as well. I made a proof of concept of such a module several years ago. It was based on madwifi back then, but the code is mostly generic. You can find it here: http://git.openwrt.org/?p=packages.git;a=tree;f=net/wprobe/src When implemented properly, such am module would even make things a lot easier for you by letting you add new stats at runtime without changing kernel code or reloading modules. So let's stop wasting time on keeping lots of tiny useless hacks around and instead build something more useful. :) - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
Am 28.04.2013 17:03, schrieb Oleksij Rempel: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: 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 li...@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. Sure. Now i need some help. Why there is no traces of radiotap in ath9k. Some other drivers have them? Do it communicate in some different way or there is just no radiotap support in ath9k? -- Regards, Oleksij ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH RFC] ath9k: collect statistics about Rx-Dup and Rx-STBC packets
On 2013-04-28 9:19 PM, Oleksij Rempel wrote: Am 28.04.2013 17:03, schrieb Oleksij Rempel: Am 28.04.2013 16:13, schrieb Oleksij Rempel: Am 28.04.2013 14:51, schrieb Felix Fietkau: 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 li...@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. Sure. Now i need some help. Why there is no traces of radiotap in ath9k. Some other drivers have them? Do it communicate in some different way or there is just no radiotap support in ath9k? radiotap is generated in mac80211, so there's no need for the driver to do it. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
