Linux wireless drivers development
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org
Subject: Performance problems with Netgear WNDAP350
Date: Mon, 9 Sep 2013 16:25:44 -0500	[thread overview]
Message-ID: <20130909212544.GA27771@thinkpad-t410> (raw)

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

             reply	other threads:[~2013-09-09 21:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09 21:25 Seth Forshee [this message]
2013-09-10  8:37 ` Performance problems with Netgear WNDAP350 Sujith Manoharan
2013-09-10 13:55   ` Seth Forshee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130909212544.GA27771@thinkpad-t410 \
    --to=seth.forshee@canonical.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox