[ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics

[ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics

[Adrian Chadd]

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

[ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics

[Ben Greear]

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 <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics

[Adrian Chadd]

On 23 March 2012 10:18, Ben Greear <greearb@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

[ath9k-devel] [ath5k-devel] Request for help: gui toolkit creation for atheros PHY/MAC statistics

[Qasim Javed]

In addition to driver statistics, I was thinking that a tool like this
should provide more insight like how many times the CPU is being
interrupted by the Wifi card when it is offered a certain load.

I was recently running into an issue with an XR9 card and
interestingly I found using the "mpstat" tool that when the offered
load goes beyond a certain threshold Mbps, the number of interrupts
per second goes down!

ath9k has a set of patches (compat wireless with "-pc" at the end of
filename before the extension) that dump the TX/RX descriptors which
contain rich information regarding the transmission and reception
process. I had to write a custom script to process the binary dumps
generated by those patches, but if the visualization tool can display
that information it would be awesome. Those binary dumps contain
almost all the information that could possibly be made available.

-Qasim
On Fri, Mar 23, 2012 at 12:25 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 23 March 2012 10:18, Ben Greear <greearb@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 at lists.ath5k.org
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel