[ath5k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics
Hi all,
I'd like some help in writing a GUI toolkit for recording, playing
back and visualising some of the PHY/MAC statistics the Atheros NICs
expose.
What I can do: help with the MAC/PHY side of things, identify what
initial things would be good to support and what would actually be
useful.
What I can't do: dedicate time to write a GUI. :-)
What I'd like to see: something completely free/open source written so
we can improve the foss wireless development process.
(Why I'm doing this: I'm fed up staring at printf() debugging in
ath9k/FreeBSD and it's hard to have others visualise what's going on
..)
I'd like it to be in C++/QT (before you ask - if you can make python
or ${OTHER_LANG} handle the sheer rates of wifi traffic, MAC counters
and PHY errors, _live_, and on tablet/atom class hardware, then please
by all means do so..) and I'd like it to be platform portable. That
way it can be used as a visualisation tool on other platforms, even if
it's unable to do live capture itself (think MacOSX/Windows.)
I'm talking about peaking on upwards of 10,000 PHY events a second in
a very noisy environment, as well as the potential for some frequency
domain analysis of time series data. This is why I think C++ is a more
suitable target language over anything scripting-y.
If you're interested in this then please drop me a private line and
we'll get this off the ground.
Thanks,
Adrian
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics
On 03/23/2012 10:07 AM, Adrian Chadd wrote:
Hi all,
I'd like some help in writing a GUI toolkit for recording, playing
back and visualising some of the PHY/MAC statistics the Atheros NICs
expose.
What I can do: help with the MAC/PHY side of things, identify what
initial things would be good to support and what would actually be
useful.
What I can't do: dedicate time to write a GUI. :-)
What I'd like to see: something completely free/open source written so
we can improve the foss wireless development process.
(Why I'm doing this: I'm fed up staring at printf() debugging in
ath9k/FreeBSD and it's hard to have others visualise what's going on
..)
I'd like it to be in C++/QT (before you ask - if you can make python
or ${OTHER_LANG} handle the sheer rates of wifi traffic, MAC counters
and PHY errors, _live_, and on tablet/atom class hardware, then please
by all means do so..) and I'd like it to be platform portable. That
way it can be used as a visualisation tool on other platforms, even if
it's unable to do live capture itself (think MacOSX/Windows.)
I wouldn't ask someone to do it and then tell them what language. Just suggest
to them what it needs to do instead.
The big question for me is: How do you propose to get the info out
of the driver and up to user-space?
Just in case it matters...while benchmarking my Linux ethtool patch to ath9k,
I found it took around 35us to make the ethtool ioctl call to get the
stats. This was on a dual-core Atom system.
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics
On 23 March 2012 10:18, Ben Greear gree...@candelatech.com wrote: I wouldn't ask someone to do it and then tell them what language. Just suggest to them what it needs to do instead. I'm sorry if it came across as demanding. It's more that I've looked at how/where people tend to use these kinds of visualisation tools and they're not on quad-core i7 laptops. They're on little itty atom netbooks (or tablets these days, I guess) with comparitively limited CPU. I've also had people suggest C#. Which is fine, but as I'd like this to be totally open source, I don't want it to depend upon any closed source C# libraries or any microsoft only runtime bits. Same holds for any other language. The other thing is keeping multiple threads going so your UI doesn't become unresponsive when you're falling behind doing network/disk IO or math operations. Yes, I've written some GUI stuff, so I have a basic idea of what's going on. If someone wants to me prove me wrong by demonstrating it done in python or some other scripting language then fine. The big question for me is: How do you propose to get the info out of the driver and up to user-space? I'll worry about that later. For FreeBSD, the PHY errors come out via radiotap, so it'll look like a BPF stream. Just in case it matters...while benchmarking my Linux ethtool patch to ath9k, I found it took around 35us to make the ethtool ioctl call to get the stats. This was on a dual-core Atom system. Right, but you can fetch a whole lot of statistics each call. The ath/HAL ioctl API doesn't return a single stat on each invocation. It returns a whole swath of them. I'm not worried about extracting the data from the various flavours of wifi stacks we're working with in BSD/Linux. :-) Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] Problem with XR9
Hi everyone, I have a question regarding a problem I have been facing while using an Ubiquiti XR9 Wifi card. This is basically a Wifi card which operates in the 900MHz band and is based on the Atheros 5414 (supports 802.11b/g) chipset. There is an open source driver (mainly maintained by Atheros and contributions from others) called ath5k. For a research problem, I wanted to measure the amount of time elapsed between when a packet enters the MAC layer queues (in this case mac80211 transmit queue) and when it is actually transmitted over the air. Measuring the entry into the MAC layer is easy as the stack runs on the Host CPU and can be instrumented. For the exact time when the frame is actually transmitted, the card provides support for reading that information. More specifically, whenever a frame is transmitted, a transmission status descriptor can be read. This transmission status descriptor contains the exact timestamp (in TUs) at which the last successful frame transmission attempt was made. Interestingly enough, when I take the difference of two timestamps, I get really large values on the order of 200,000 microseconds. This only happens when there is a lot of data to send such as when using iperf. On the other hand, if I just use ping and then look at the value measured above, they are fine. I measured the values when there was no contention from any other node (experiments were carried out over a testbed where nodes are connected via coaxial cables). So, basically I get large bloated values only when there are lot of transmission attempts back to back. I tried moving the point at which the first timestamp is taken as close to the hardware as possible i.e. just before the frame is DMA'ed to the card. I get the same large values which indicates that delays are not being incurred due to queues on the host. Also, instead of depending on the card for providing the second timestamp (the time at which the frame is put on air), I tried to measure it myself within an interrupt handler which is invoked whenever the host CPU is interrupted by an interrupt generated as a result of receiving a frame on the Wifi card. Also, in this case I get large values as before. This indicates that the mechanism used to take the transmit timestamp on the card is working fine. I did some further research using the mpstat tool and found that the number of interrupts per second (corresponding to the received frames) generated by the card goes down if the offered load exceeds a certain threshold. This seems to indicate that there is some problem in the code running on the cards's own processor as the number of interrupts going down as a result of more offered load is ungraceful behavior. I was wondering if you could offer some insight into this or ways to solve this problem? Thanks and regards, -Qasim ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
