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
