Send users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com

or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."


Today's Topics:

   1. Re: [[email protected]: [Bug 42828]
      rt2800pci unstable - chokes after too much I/O] (Stanislaw Gruszka)
   2. Re: [[email protected]: [Bug 42828]
      rt2800pci unstable - chokes after too much I/O] (Andreas Hartmann)
   3. Re: [[email protected]: [Bug 42828]
      rt2800pci unstable - chokes after too much I/O] (Stanislaw Gruszka)


----------------------------------------------------------------------

Message: 1
Date: Fri, 16 Nov 2012 11:47:29 +0100
From: Stanislaw Gruszka <[email protected]>
To: Andreas Hartmann <[email protected]>
Cc: [email protected],      Francisco Pina Martins
        <[email protected]>
Subject: Re: [rt2x00-users] [[email protected]: [Bug
        42828] rt2800pci unstable - chokes after too much I/O]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

On Fri, Nov 16, 2012 at 11:30:57AM +0100, Andreas Hartmann wrote:
> > 
> > Ok, I'm voting for reverting both commits:
> > 
> > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
> > Author: Andreas Hartmann <[email protected]>
> > Date:   Tue Apr 17 00:25:28 2012 +0200
> > 
> >     rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
> > 
> > commit f0425beda4d404a6e751439b562100b902ba9c98
> > Author: Felix Fietkau <[email protected]>
> > Date:   Sun Aug 28 21:11:01 2011 +0200
> > 
> >     mac80211: retry sending failed BAR frames later instead of tearing down 
> > aggr
> > 
> > f0425beda is causing troubles on rt2800 because that hardware do not
> > report BAR ack (perhaps because it is acked by BA frame not ACK frame),
> > so we constantly send BAR frames with the same SSN. This can be hardware
> > problem, but also if we can jump into that simulation if remote station
> > will not ack BAR frames or due to noisy radio conditions.

[snip]

> Taking all these facts into consideration (and some older measurements,
> too), the only thing I can say so far:
> 
> Until now, I can't say for sure, if there is any significant difference
> between the actual situation and the proposed patches by Stanislaw. But
> you may come to another conclusion if you analyse the measurement with
> your know how and background.

The goal here is to fix regression caused by commit be03d4a45c, not
to improve performance.

Stanislaw



------------------------------

Message: 2
Date: Fri, 16 Nov 2012 14:58:49 +0100
From: Andreas Hartmann <[email protected]>
To: Stanislaw Gruszka <[email protected]>
Cc: [email protected],      Francisco Pina Martins
        <[email protected]>
Subject: Re: [rt2x00-users] [[email protected]: [Bug
        42828] rt2800pci unstable - chokes after too much I/O]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

Stanislaw Gruszka schrieb:
> On Fri, Nov 16, 2012 at 11:30:57AM +0100, Andreas Hartmann wrote:
>>>
>>> Ok, I'm voting for reverting both commits:
>>>
>>> commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
>>> Author: Andreas Hartmann <[email protected]>
>>> Date:   Tue Apr 17 00:25:28 2012 +0200
>>>
>>>     rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
>>>
>>> commit f0425beda4d404a6e751439b562100b902ba9c98
>>> Author: Felix Fietkau <[email protected]>
>>> Date:   Sun Aug 28 21:11:01 2011 +0200
>>>
>>>     mac80211: retry sending failed BAR frames later instead of tearing down 
>>> aggr
>>>
>>> f0425beda is causing troubles on rt2800 because that hardware do not
>>> report BAR ack (perhaps because it is acked by BA frame not ACK frame),
>>> so we constantly send BAR frames with the same SSN. This can be hardware
>>> problem, but also if we can jump into that simulation if remote station
>>> will not ack BAR frames or due to noisy radio conditions.
> 
> [snip]
> 
>> Taking all these facts into consideration (and some older measurements,
>> too), the only thing I can say so far:
>>
>> Until now, I can't say for sure, if there is any significant difference
>> between the actual situation and the proposed patches by Stanislaw. But
>> you may come to another conclusion if you analyse the measurement with
>> your know how and background.
> 
> The goal here is to fix regression caused by commit be03d4a45c, not
> to improve performance.

Why do you think, I would think it would improve performance?


Regards,
Andreas



------------------------------

Message: 3
Date: Fri, 16 Nov 2012 16:07:54 +0100
From: Stanislaw Gruszka <[email protected]>
To: Andreas Hartmann <[email protected]>
Cc: [email protected],      Francisco Pina Martins
        <[email protected]>
Subject: Re: [rt2x00-users] [[email protected]: [Bug
        42828] rt2800pci unstable - chokes after too much I/O]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

On Fri, Nov 16, 2012 at 02:58:49PM +0100, Andreas Hartmann wrote:
> > The goal here is to fix regression caused by commit be03d4a45c, not
> > to improve performance.
> 
> Why do you think, I would think it would improve performance?

Performance should be the same as it was before the commits were applied.

Stanislaw



------------------------------

Subject: Digest Footer

_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com


------------------------------

End of users Digest, Vol 45, Issue 14
*************************************

Reply via email to