linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Performance problems with Netgear WNDAP350
@ 2013-09-09 21:25 Seth Forshee
  2013-09-10  8:37 ` Sujith Manoharan
  0 siblings, 1 reply; 3+ messages in thread
From: Seth Forshee @ 2013-09-09 21:25 UTC (permalink / raw)
  To: Johannes Berg, linux-wireless

After the previous fix to deal with invalid ECSA IEs in probe response
frames, I've received more reports of trouble with this AP. I've been
experimenting with one and have uncovered some odd behavior that I'm not
sure how to deal with.

I've found in testing TCP throughput with iperf that the performance
ranges from somewhat inconsistent to downright terrible with Linux STAs.
I've tried iwlwifi, ath9k, and brcmsmac, and all are similar. I also
tested with OSX, and while performance is pretty inconsistent it never
gets to the point of being absolutely terrible. My test setup has the
iperf server behind the APs ethernet interface with the client on the
STA.

What I'm seeing under wireshark is that everything seems to go fine for
a while, but sometimes the AP is failing to transmit the TCP ACKs from
the iperf server to the STA in a timely fashion. This delay can be
seconds in length, and I see it with iwlwifi, ath9k, and brcmsmac. I've
run wireshark on my iperf server, and the delays do not show up between
the same ACKs there.

I see the delays when running the iperf client on OSX too, but they're
never quite as bad. The difference seems to be that once the TCP window
is exhaused, OSX enables power save for a couple hundred msecs before
retransmitting. This somehow seems to get the AP to transmit the frames
(though the TIM never indicates that there are any buffered frames). I
don't see the problem if I prevent the AP from transmitting A-MPDUs,
even if the STAs continue using aggregation.

So it seems apparent that this AP has issues. I'm hoping to solicit some
suggestions on how we might be able to deal with it. I could try to
emulate the behavior I see from OSX, but that won't help for drivers
that don't support power save.

I posted some wireshark traces in case someone else can find something
else informative that I've missed. They're at
http://people.canonical.com/~sforshee/wndap350/:

 * iperf-iwlwifi.pcapng.gz: Trace from iperf client on Linux STA with
   iwlwifi
 * iperf-server.pcapng.gz: Trace from the iperf server for the same test
   as iperf-iwlwifi
 * iperf-osx.pcapng.gz: Trace from iperf client on OSX, using Broadcom
   wireless

I'm happy to collect more data if there's anything else that would be
useful.

Thanks,
Seth

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Performance problems with Netgear WNDAP350
  2013-09-09 21:25 Performance problems with Netgear WNDAP350 Seth Forshee
@ 2013-09-10  8:37 ` Sujith Manoharan
  2013-09-10 13:55   ` Seth Forshee
  0 siblings, 1 reply; 3+ messages in thread
From: Sujith Manoharan @ 2013-09-10  8:37 UTC (permalink / raw)
  To: Seth Forshee; +Cc: Johannes Berg, linux-wireless

Seth Forshee wrote:
> I posted some wireshark traces in case someone else can find something
> else informative that I've missed. They're at
> http://people.canonical.com/~sforshee/wndap350/:
> 
>  * iperf-iwlwifi.pcapng.gz: Trace from iperf client on Linux STA with
>    iwlwifi
>  * iperf-server.pcapng.gz: Trace from the iperf server for the same test
>    as iperf-iwlwifi
>  * iperf-osx.pcapng.gz: Trace from iperf client on OSX, using Broadcom
>    wireless

The link with the iwlwifi client seems to be drowning in RTS/CTS exchanges
compared with the osx client.

iwlwifi: total: 109087, RTS - 9782 (9.0 %)
osx:     total: 522581, RTS - 8366 (1.6 %)

Sujith

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Performance problems with Netgear WNDAP350
  2013-09-10  8:37 ` Sujith Manoharan
@ 2013-09-10 13:55   ` Seth Forshee
  0 siblings, 0 replies; 3+ messages in thread
From: Seth Forshee @ 2013-09-10 13:55 UTC (permalink / raw)
  To: Sujith Manoharan; +Cc: Johannes Berg, linux-wireless

On Tue, Sep 10, 2013 at 02:07:48PM +0530, Sujith Manoharan wrote:
> Seth Forshee wrote:
> > I posted some wireshark traces in case someone else can find something
> > else informative that I've missed. They're at
> > http://people.canonical.com/~sforshee/wndap350/:
> > 
> >  * iperf-iwlwifi.pcapng.gz: Trace from iperf client on Linux STA with
> >    iwlwifi
> >  * iperf-server.pcapng.gz: Trace from the iperf server for the same test
> >    as iperf-iwlwifi
> >  * iperf-osx.pcapng.gz: Trace from iperf client on OSX, using Broadcom
> >    wireless
> 
> The link with the iwlwifi client seems to be drowning in RTS/CTS exchanges
> compared with the osx client.
> 
> iwlwifi: total: 109087, RTS - 9782 (9.0 %)
> osx:     total: 522581, RTS - 8366 (1.6 %)

Yes, but I don't think that's behind the APs failure to send us frames
for long periods of time. I can better compare the RTS/CTS exchanges
between the two when I can get an otherwise stable connection to the AP
from Linux.

Seth

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-09-10 13:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-09 21:25 Performance problems with Netgear WNDAP350 Seth Forshee
2013-09-10  8:37 ` Sujith Manoharan
2013-09-10 13:55   ` Seth Forshee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).