Hi all, today I played around with backports and I also tried to compile a new kernel version for my Linux PC but I wasn't able to get debugfs running. I don't get any files in the ieee80211 directory.
Any ideas? Would be great! Best regards, Marco >-----Ursprüngliche Nachricht----- >Von: Steger, Marco >Gesendet: Montag, 16. Februar 2015 11:29 >An: Steger, Marco; [email protected] >Betreff: AW: 802.11s performance testing - tools and tips > >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
