Hi all, after my vacation and some research about debugfs I have a short question: I read several times about enabling debugfs for the ath9k_htc (e.g. [1]). Am I right that this means, that I will have to compile the ath9k_htc on myself? (I'm using debian 3.19) If yes, what would be the easiest way to get the required source?
Best regards, Marco [1] https://wireless.wiki.kernel.org/en/users/Drivers/ath9k/debug#ath9k_and_ath9k_htc_debugging >-----Ursprüngliche Nachricht----- >Von: Devel [mailto:[email protected]] Im Auftrag von Steger, >Marco via Devel >Gesendet: Mittwoch, 21. Jänner 2015 17:23 >An: Bob Copeland; [email protected] >Betreff: AW: 802.11s performance testing - tools and tips > >Hi Bob, dear all! > >Thanks for your explanations. So the data rate will (probably) decrease >automatically while increasing the distance between two nodes? There is no way >to tell the nodes that the must use e.g. 54.0 MBit/s all the time? (sorry if >this is a >very stupid newbie question... ;) ). So the best way will be to periodically >use ' iw >dev mesh station dump ' during the measurements to get the current bit rate? Am >I right? > >Thanks for the hint regarding debugfs. I have never used this before so I will >have >to learn more about it. But after a quick google search I think I basically >will have >to check the files in ' /sys/kernel/debug/ieee80211/phy0/ ' but this folder is >empty on my BeagleBone board. How to configure this? Will I have to recompile >my ath9k driver or something like that. I found >http://wireless.kernel.org/en/users/Drivers/ath9k/debug but I'm not really sure >how to start. Would be great if you guys can give me a hint... > >Best regards, >Marco > > > >>-----Ursprüngliche Nachricht----- >>Von: Bob Copeland [mailto:[email protected]] >>Gesendet: Mittwoch, 21. Jänner 2015 16:09 >>An: Steger, Marco; [email protected] >>Cc: Yeoh Chun-Yeow >>Betreff: Re: 802.11s performance testing - tools and tips >> >>On Wed, Jan 21, 2015 at 11:28:32AM +0000, Steger, Marco via Devel wrote: >>> Are there any parameters which will change while I'm increasing the >>> distance between the two nodes? Bit rate? Anything else? Any parameter >>> which can probably change? (I really want to have a clear and proper >>> result) >> >>You can expect rate to decrease as distance increases. In practice, it's >>difficult >to >>control for the channel conditions in such an experiment, because small >>movements may cause large changes in the channel properties. >> >>> To get the packet error rate I want to periodically/permanently send >>> message from one node to the other one. Can I use normal UDP packets >>> for that? Is there a possibility to send packets on a lower layer in >>> Linux? (I think raw Ethernet sockets will be helpful but I will have >>> to investigate some more here) >> >>You may wish to distinguish (layer 3) packet loss and (layer 2) frame loss. >>The frame loss is probably the more interesting number... for that I believe >>there >>are some counters you can use that are exported in debugfs. >> >>Note that for unicast traffic over wifi, there is a retry mechanism at the MAC >>layer, so some levels of frame loss may not show up as UDP packet loss but as >>latency instead. >> >>For multicast traffic, there's no retry, but there's also no rate scaling. >> >>Relevant to mesh: besides channel conditions, latency and bandwidth are also >>determined by the number of nodes that are communicating, because only one >>station in a given listening area can transmit at a time. So consider that >>in a 3- >>node, multihop scenario (A<->B<->C), you'll probably see a factor of 2 >>reduction >>in achievable throughput compared to just two nodes. >> >>-- >>Bob Copeland %% http://bobcopeland.com/ >_______________________________________________ >Devel mailing list >[email protected] >http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
