* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
@ 2010-07-21 22:17 ` Björn Smedman
0 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-21 22:17 UTC (permalink / raw)
To: ath9k-devel
Hi all,
I just tried out compat-wireless-2010-07-16 on AR913x (with
openwrt/trunk at r22321) and saw some weird performance problems.
First, with the default 11n HT20 AP configuration I get really good
performance on an old 11g MacBook. 16Mbps downloads limited by WAN. :)
But then I try a newer 11n MacBook and performance absolutely sucks.
2-3Mbps downloads with erratic bursts and "hangs".
So, I start to think something is wrong with 11n and reconfigure for
11g only. Then the 11g MacBook performance also sucks. The same
2-3Mbps downloads with erratic bursts and "hangs". So 11n AP and 11g
client is good, but 11g AP and 11g client sucks. Looking at the
rc_stats it seems like tx completely breaks down from time to time:
root at OpenWrt:/sys/kernel/debug/ieee80211/phy0# cat stations/00\:17\:f2\:51\:b2\:
2d/rc_stats
rate throughput ewma prob this prob this succ/attempt
success attempts
t 1 0.1 18.3 0.0 0( 19) 28 731
2 0.0 0.0 0.0 0( 0) 0 18
5.5 0.0 0.0 0.0 0( 0) 0 10
11 0.0 0.0 0.0 0( 0) 0 14
6 0.0 0.0 0.0 0( 0) 0 11
9 0.0 0.0 0.0 0( 0) 0 18
12 0.0 0.0 0.0 0( 0) 0 12
18 0.0 0.0 0.0 0( 0) 0 16
24 0.0 0.0 0.0 0( 0) 0 18
36 0.1 0.4 0.0 0( 0) 2 1824
48 0.0 0.0 0.0 0( 2) 0 16
T P 54 27.3 63.1 0.0 0(180) 4749 13896
Total packet count:: ideal 4780 lookaround 532
That's in exactly the same spot I was getting 16Mbps consistently with
AP was 11n!
Any debuging I can do to help? Bisecting is unfortunately a lot of
work on this embedded system...
/Bj?rn
^ permalink raw reply [flat|nested] 10+ messages in thread
* ath9k: performance regressions / tx semi-stuck somehow
@ 2010-07-21 22:17 ` Björn Smedman
0 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-21 22:17 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
Hi all,
I just tried out compat-wireless-2010-07-16 on AR913x (with
openwrt/trunk@r22321) and saw some weird performance problems.
First, with the default 11n HT20 AP configuration I get really good
performance on an old 11g MacBook. 16Mbps downloads limited by WAN. :)
But then I try a newer 11n MacBook and performance absolutely sucks.
2-3Mbps downloads with erratic bursts and "hangs".
So, I start to think something is wrong with 11n and reconfigure for
11g only. Then the 11g MacBook performance also sucks. The same
2-3Mbps downloads with erratic bursts and "hangs". So 11n AP and 11g
client is good, but 11g AP and 11g client sucks. Looking at the
rc_stats it seems like tx completely breaks down from time to time:
root@OpenWrt:/sys/kernel/debug/ieee80211/phy0# cat stations/00\:17\:f2\:51\:b2\:
2d/rc_stats
rate throughput ewma prob this prob this succ/attempt
success attempts
t 1 0.1 18.3 0.0 0( 19) 28 731
2 0.0 0.0 0.0 0( 0) 0 18
5.5 0.0 0.0 0.0 0( 0) 0 10
11 0.0 0.0 0.0 0( 0) 0 14
6 0.0 0.0 0.0 0( 0) 0 11
9 0.0 0.0 0.0 0( 0) 0 18
12 0.0 0.0 0.0 0( 0) 0 12
18 0.0 0.0 0.0 0( 0) 0 16
24 0.0 0.0 0.0 0( 0) 0 18
36 0.1 0.4 0.0 0( 0) 2 1824
48 0.0 0.0 0.0 0( 2) 0 16
T P 54 27.3 63.1 0.0 0(180) 4749 13896
Total packet count:: ideal 4780 lookaround 532
That's in exactly the same spot I was getting 16Mbps consistently with
AP was 11n!
Any debuging I can do to help? Bisecting is unfortunately a lot of
work on this embedded system...
/Björn
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
2010-07-21 22:17 ` Björn Smedman
@ 2010-07-22 0:32 ` Felix Fietkau
-1 siblings, 0 replies; 10+ messages in thread
From: Felix Fietkau @ 2010-07-22 0:32 UTC (permalink / raw)
To: ath9k-devel
On 2010-07-22 12:17 AM, Bj?rn Smedman wrote:
> Hi all,
>
> I just tried out compat-wireless-2010-07-16 on AR913x (with
> openwrt/trunk at r22321) and saw some weird performance problems.
>
> That's in exactly the same spot I was getting 16Mbps consistently with
> AP was 11n!
>
> Any debuging I can do to help? Bisecting is unfortunately a lot of
> work on this embedded system...
Could you please try if the earlier version that was in OpenWrt
(2010-07-06) has the same issues?
- Felix
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
@ 2010-07-22 0:32 ` Felix Fietkau
0 siblings, 0 replies; 10+ messages in thread
From: Felix Fietkau @ 2010-07-22 0:32 UTC (permalink / raw)
To: Björn Smedman; +Cc: ath9k-devel, linux-wireless
On 2010-07-22 12:17 AM, Björn Smedman wrote:
> Hi all,
>
> I just tried out compat-wireless-2010-07-16 on AR913x (with
> openwrt/trunk@r22321) and saw some weird performance problems.
>
> That's in exactly the same spot I was getting 16Mbps consistently with
> AP was 11n!
>
> Any debuging I can do to help? Bisecting is unfortunately a lot of
> work on this embedded system...
Could you please try if the earlier version that was in OpenWrt
(2010-07-06) has the same issues?
- Felix
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
2010-07-22 0:32 ` Felix Fietkau
@ 2010-07-22 22:56 ` Björn Smedman
-1 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-22 22:56 UTC (permalink / raw)
To: ath9k-devel
2010/7/22 Felix Fietkau <nbd@openwrt.org>:
> On 2010-07-22 12:17 AM, Bj?rn Smedman wrote:
>> Hi all,
>>
>> I just tried out compat-wireless-2010-07-16 on AR913x (with
>> openwrt/trunk at r22321) and saw some weird performance problems.
>>
> Could you please try if the earlier version that was in OpenWrt
> (2010-07-06) has the same issues?
>
Quickly flashing the builds I have on hand I came up with this small
table comparing MacBook 11g and 11n clients for various openwrt/trunk
versions:
r21960P (compat-wireless-2010-06-15): 11g = 12Mbps, 11n = 7.2Mbps
r22286 (compat-wireless-2010-07-06): 11g = 7.2Mbps*, 11n = 4.2Mbps*
r22321 (compat-wireless-2010-07-16): 11g = 12Mbps*, 11n = 2.9Mbps*
(*) Bursty / unstable performance.
(P) Some patches of my own on top of openwrt.
I realize it doesn't say very much unfortunately...
/Bj?rn
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
@ 2010-07-22 22:56 ` Björn Smedman
0 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-22 22:56 UTC (permalink / raw)
To: Felix Fietkau; +Cc: ath9k-devel, linux-wireless
2010/7/22 Felix Fietkau <nbd@openwrt.org>:
> On 2010-07-22 12:17 AM, Björn Smedman wrote:
>> Hi all,
>>
>> I just tried out compat-wireless-2010-07-16 on AR913x (with
>> openwrt/trunk@r22321) and saw some weird performance problems.
>>
> Could you please try if the earlier version that was in OpenWrt
> (2010-07-06) has the same issues?
>
Quickly flashing the builds I have on hand I came up with this small
table comparing MacBook 11g and 11n clients for various openwrt/trunk
versions:
r21960P (compat-wireless-2010-06-15): 11g = 12Mbps, 11n = 7.2Mbps
r22286 (compat-wireless-2010-07-06): 11g = 7.2Mbps*, 11n = 4.2Mbps*
r22321 (compat-wireless-2010-07-16): 11g = 12Mbps*, 11n = 2.9Mbps*
(*) Bursty / unstable performance.
(P) Some patches of my own on top of openwrt.
I realize it doesn't say very much unfortunately...
/Björn
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
2010-07-22 22:56 ` Björn Smedman
@ 2010-07-26 23:36 ` Björn Smedman
-1 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-26 23:36 UTC (permalink / raw)
To: ath9k-devel
2010/7/23 Bj?rn Smedman <bjorn.smedman@venatech.se>:
> 2010/7/22 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-07-22 12:17 AM, Bj?rn Smedman wrote:
>>> I just tried out compat-wireless-2010-07-16 on AR913x (with
>>> openwrt/trunk at r22321) and saw some weird performance problems.
>>>
>> Could you please try if the earlier version that was in OpenWrt
>> (2010-07-06) has the same issues?
I had some trouble reproducing this but now I feel convinced that this
performance issue was caused by interference, although I think ath9k
could do a better job in difficult radio environments.
Note how downstream throughput goes from ~55 Mbps down to around 3
Mbps. Nothing is moved in this experiment.
bjorn-smedmans-macbook-2:~ bjornsmedman$ iperf -w 256K -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 256 KByte
------------------------------------------------------------
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58060
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 194 MBytes 54.1 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58926
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 203 MBytes 56.6 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58990
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 190 MBytes 53.2 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 59236
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 189 MBytes 52.8 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64327
[Some interference source probably comes in here]
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-34.5 sec 5.64 MBytes 1.37 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64424
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.3 sec 8.06 MBytes 2.23 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64625
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-31.3 sec 13.6 MBytes 3.64 Mbits/sec
If I then switch the AP channel (from 1 to 11) performance is looking
good again:
bjorn-smedmans-macbook-2:~ bjornsmedman$ iperf -w 256K -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 256 KByte
------------------------------------------------------------
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55550
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-120.0 sec 621 MBytes 43.4 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55562
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-120.0 sec 764 MBytes 53.4 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55568
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 68.1 MBytes 56.9 Mbits/sec
/Bj?rn
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
@ 2010-07-26 23:36 ` Björn Smedman
0 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-26 23:36 UTC (permalink / raw)
To: Felix Fietkau; +Cc: ath9k-devel, linux-wireless
2010/7/23 Björn Smedman <bjorn.smedman@venatech.se>:
> 2010/7/22 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-07-22 12:17 AM, Björn Smedman wrote:
>>> I just tried out compat-wireless-2010-07-16 on AR913x (with
>>> openwrt/trunk@r22321) and saw some weird performance problems.
>>>
>> Could you please try if the earlier version that was in OpenWrt
>> (2010-07-06) has the same issues?
I had some trouble reproducing this but now I feel convinced that this
performance issue was caused by interference, although I think ath9k
could do a better job in difficult radio environments.
Note how downstream throughput goes from ~55 Mbps down to around 3
Mbps. Nothing is moved in this experiment.
bjorn-smedmans-macbook-2:~ bjornsmedman$ iperf -w 256K -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 256 KByte
------------------------------------------------------------
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58060
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 194 MBytes 54.1 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58926
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 203 MBytes 56.6 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 58990
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 190 MBytes 53.2 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 59236
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.0 sec 189 MBytes 52.8 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64327
[Some interference source probably comes in here]
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-34.5 sec 5.64 MBytes 1.37 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64424
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-30.3 sec 8.06 MBytes 2.23 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 64625
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-31.3 sec 13.6 MBytes 3.64 Mbits/sec
If I then switch the AP channel (from 1 to 11) performance is looking
good again:
bjorn-smedmans-macbook-2:~ bjornsmedman$ iperf -w 256K -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 256 KByte
------------------------------------------------------------
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55550
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-120.0 sec 621 MBytes 43.4 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55562
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-120.0 sec 764 MBytes 53.4 Mbits/sec
[ 4] local 192.168.78.119 port 5001 connected with 192.168.78.211 port 55568
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 68.1 MBytes 56.9 Mbits/sec
/Björn
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
2010-07-26 23:36 ` Björn Smedman
(?)
@ 2010-07-26 23:41 ` Peter Stuge
2010-07-27 9:46 ` Björn Smedman
-1 siblings, 1 reply; 10+ messages in thread
From: Peter Stuge @ 2010-07-26 23:41 UTC (permalink / raw)
To: ath9k-devel
Bj?rn Smedman wrote:
> If I then switch the AP channel (from 1 to 11) performance is looking
> good again:
Does it stay consistent and associated for you over say a weekend in
an office building, or a work week, or a month?
//Peter
^ permalink raw reply [flat|nested] 10+ messages in thread
* [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
2010-07-26 23:41 ` Peter Stuge
@ 2010-07-27 9:46 ` Björn Smedman
0 siblings, 0 replies; 10+ messages in thread
From: Björn Smedman @ 2010-07-27 9:46 UTC (permalink / raw)
To: ath9k-devel
On Tue, Jul 27, 2010 at 1:41 AM, Peter Stuge <peter@stuge.se> wrote:
> Bj?rn Smedman wrote:
>> If I then switch the AP channel (from 1 to 11) performance is looking
>> good again:
>
> Does it stay consistent and associated for you over say a weekend in
> an office building, or a work week, or a month?
I haven't tried leaving it associated over a long period of time. The
use case that is most important for me is residential use with a lot
of relatively short sessions.
I will say this however: there has been some amazing progress in the
stability of ath9k over the last few months. A lot of really good
stability patches coming in now, especially if you have an older
chipset.
I think Felix mentioned a future mainline kernel where he thinks ath9k
in ap mode should be stable. I forgot the number, but just hearing
that kind of ambition from someone who can actually make it happen is
good enough for me. :)
/Bj?rn
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-07-27 9:46 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-21 22:17 [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow Björn Smedman
2010-07-21 22:17 ` Björn Smedman
2010-07-22 0:32 ` [ath9k-devel] " Felix Fietkau
2010-07-22 0:32 ` Felix Fietkau
2010-07-22 22:56 ` Björn Smedman
2010-07-22 22:56 ` Björn Smedman
2010-07-26 23:36 ` Björn Smedman
2010-07-26 23:36 ` Björn Smedman
2010-07-26 23:41 ` Peter Stuge
2010-07-27 9:46 ` Björn Smedman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.