[ath9k-devel] oprofile the ath9k for low throughput rate and 3 questions

[Luis R. Rodriguez <lrodriguez@atheros.com>]

On Wed, Apr 28, 2010 at 07:17:47AM -0700, Dave Taht wrote:
> On 04/19/2010 07:05 PM, oiioeu at aol.com<mailto:oiioeu@aol.com> wrote:
> 
> I got avg. 60Mbps of the throughput rate by iperf testing and had the testing environment like below:
> 
> 
> OpenWrt:                       r18529 (I tried the latest r20851  and the throughput rate could be even worse )
> AP && STA h/w platform: IXP425
> wireless module:             AR9280( 11na, HT40 )
> wireless driver:                ath9k version matched OpenWrt r18529
> topology is like:               PC1 - STA - AP - PC2 ( ethernet connection between PC1 and STA, AP and PC2, and the wireless
>                                       connection between STA and the AP. iperf client on PC1 and iperf server on PC2 )
> 
> then I added oprofile support to this throughput rate testing and had the throughput rate decrease to avg 8Mbps, here are my questions:
> 1. whether the avg. 8Mbps of the throughput after adding the oprofile support seemed to be reasonable?
> 2. why there were the warning messeges at the beginning of the opreport result and does it matter or not?
> 3. anyone could point me is there anything abnormal from the opreport messeges that lead to the low throughput in my case?
> the oprofile log are attached
> 
> Interesting. I've been meaning to get around to oprofiling my hardware (nanostation M5) one of these days  as I'd noted that I was achieving ~70Mbit via iperf and seeing (via top) that the hardware was spending 70% of its time in the "sirq" state. (whether or not that was the wireless or wired drivers doing that, I don't know).
> 
> oprofile tends to be high overhead unless there is special on-chip counter support.
> 
> As for this particular oprofile, I don't know, but it looks like ath9k_ioread32 is a good candidate for optimization, even without the huge oprofile slowdown....

ath9k_ioread32() could be made simpler by becoming a callback after
we check for the serialization requirement. We can use a default
callback (the current one) for pre-initialization and then then we
can just peg the proper callback upon ath9k_hw_attach_ops(). The
callback for the case where serialization is not required would be
a straight forward read.

This can be done for ath9k_iowrite32() as well.

  Luis