From: Johannes Berg <johannes@sipsolutions.net>
To: Daniel Halperin <dhalperi@cs.washington.edu>
Cc: wwguy <wey-yi.w.guy@intel.com>,
"ipw3945-devel@lists.sourceforge.net"
<ipw3945-devel@lists.sourceforge.net>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: bug: iwlwifi, aggregation, and mac80211's reorder buffer
Date: Tue, 15 Mar 2011 19:52:46 +0100 [thread overview]
Message-ID: <1300215166.4139.8.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <AANLkTikieuk6CoRPzQGSMMggMc=wPEXHY5B5H2N_CB5a@mail.gmail.com>
On Tue, 2011-03-15 at 11:47 -0700, Daniel Halperin wrote:
> >> [341398.950019] iwlagn 0000:03:00.0: iwlagn_tx_agg_start on ra =
> >> 00:16:ea:c3:b3:8e tid = 0
> >> [341401.790964] New seq exceeds buffering window: 2335, 2304
> >
> > So the delta is always 31, it seems? Is iwlwifi consistently sending
> > batches of 32 instead of the advertised 31?
>
> I don't think that's the case, in fact I've never seen the hardware
> send a larger batch than frame limit.
Ok.
> I think it's from a missed
> frame early in one batch being pushed out by a late frame in the next
> batch.
Ok, yeah, that'd have the same effect.
> I know how to get the logs to find out. I have a bunch of
> meetings soon, but I'll dig into this more later.
Thanks.
> > Also -- don't get confused, the tx_agg_start is on its own TX agg
> > session, but the new seq stuff is on its RX agg session.
>
> You're absolutely true; but both sides pretty much start and stop
> aggregation in sync, they both have the same timeouts and I'm only
> using tcp traffic which is bidirectional. They're running the same
> software on the same hardware, modulo one being an AP and one a
> client.
Right, if you have bidi traffic like TCP iwlwifi's way of
starting/stopping aggregation will be in sync.
> [Yes, I know that AP mode is broken on the iwl5300 but I disable power
> save, etc., and it seems to work well enough ... Actually, does AP
> (not P2P) mode work properly on the P2P-supporting 6300? I could
> switch to using those.]
Yeah, but I wouldn't worry about it in your case right now -- the only
broken thing that I know of is all about powersave.
johannes
next prev parent reply other threads:[~2011-03-15 18:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 8:11 bug: iwlwifi, aggregation, and mac80211's reorder buffer Daniel Halperin
2011-03-11 8:13 ` Guy, Wey-Yi
2011-03-13 19:59 ` Daniel Halperin
2011-03-14 0:47 ` wwguy
2011-03-14 18:16 ` Daniel Halperin
2011-03-15 11:51 ` Johannes Berg
2011-03-15 12:52 ` Johannes Berg
2011-03-15 18:16 ` Daniel Halperin
2011-03-15 18:29 ` Johannes Berg
2011-03-15 18:31 ` Daniel Halperin
2011-03-15 18:33 ` Daniel Halperin
2011-03-15 18:41 ` Johannes Berg
2011-03-15 18:47 ` Daniel Halperin
2011-03-15 18:52 ` Johannes Berg [this message]
2011-03-14 16:24 ` Johannes Berg
2011-03-14 17:38 ` Daniel Halperin
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=1300215166.4139.8.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=dhalperi@cs.washington.edu \
--cc=ipw3945-devel@lists.sourceforge.net \
--cc=linux-wireless@vger.kernel.org \
--cc=wey-yi.w.guy@intel.com \
/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 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.