On Tuesday 27 July 2010 10:37:25 Johannes Berg wrote:
> On Tue, 2010-07-27 at 08:20 +0200, Christian Lamparter wrote:
> > This (rather _unfinished_ :-D ) patch adds a timer which
> > if trigger schedules the automatic release of all expired
> > A-MPDU frames. This implementation has the advantage that
> > all queued-up MPDU will now arrive in the network core
> > within a timely manner.
> >
> > In my "experiments", the patch helped to ironed out the
> > sudden throughput drops that have been _killing_ my
> > average tcp performance ever since I can remember.
>
> But why is your BA session so damaged to start with? This is not a
> normal situtation!
I can think of at least one possible reason:
commit 3ef83d745bf5220bef3a0fd11b96eb9ac64c8e8e
Author: Felix Fietkau <nbd@xxxxxxxxxxx>
Date: Tue May 4 09:58:57 2010 +0200
ath9k: fix another source of corrupt frames
Atheros hardware supports receiving frames that span multiple
descriptors and buffers. In this case, the rx status of every
descriptor except for the last one is invalid and may contain random
data. Because the driver does not support this, it needs to drop such
frames.
Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx>
Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx>
and obviously, the HW marked the "last one" in the BA scoreboard
as successfully received. Therefore we don't get a second attempt
because the driver dropped it :(
(The same applies to ar9170, which will print "missing tags!",
or stream corruption in such a case)
> > But there is a catch: The logs will quickly fill up with:
> > "release an RX reorder frame due to timeout on earlier frames".
> > and the package loss will goes through the roof...
> >
> > Now, I can think of several reasons why this could happen:
> > 1. we don't wait long enough for the HT peer to
> > finish their _retry_ procedure?
> >
> > 2. previously - when the stream simply _stopped_ - we had
> > to wait until the tcp retry kick in again. So we had
> > some "silent" periods and therefore less noise from
> > the reordering code?
> >
> > 3. ->bugs<- but where are they?
>
> I'm having a hard time understanding this patch, can you split out the
> no-op code reorg parts or explain what it does?
Sure, just finished clean-up.
Regards,
Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
