[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]

Francisco Pina Martins f.pinamartins at gmail.com
Wed Nov 21 08:59:29 AEDT 2012


Sorry about that, I blame gmail's keyboard short cuts...
Ahem!
* Good reception conditions: less than 2m away from the AP, with nothing
but air between it and my netbook.
* Poor reception conditions: About 8-9m away from the AP, with 3 walls and
a door between it and my netbook.
No other devices are connected to this AP during the testing. However,
people sometimes get between the AP and the netbook on the poor testing
conditions (I also don't have a lab for these tests).
* Control data: Linux 3.0 (LTS kernel from Arch Linux [core] repository)
* Bugged data: Linux 3.6 (Stock kernel from Arch Linux [core] repository)
* Patched data: Linux 3.7-rc5 with the 2 reverted commits and Stanislaw's
patch (Compiled from the PKGBUILD in Arch Linux [testing] repository with
the patches added in)

I should also state that where I live there are tenths of wireless networks
and all the channels are used by at least one other network.
The test were run in different times (obviously) so the amount of other
computers using other networks has likely differed during the data
collection time. This could eventually explain the differences between the
control and the patched data.

It is evident from the data presented that the patches seem to completely
solve the problem in this case.

Once again, thank you for your attention and paches.


On 20 November 2012 21:43, Francisco Pina Martins
<f.pinamartins at gmail.com>wrote:

> Here are the graphs as promised. =-)
> Test conditions once again:
> * Good reception conditions:
>
> The improvements are vast.
>
>
>
>
> On 20 November 2012 09:49, Francisco Pina Martins <f.pinamartins at gmail.com
> > wrote:
>
>> I have been testing Stanislaw's patch and I can confirm that it's quite
>> an improvement. It's even (very) slightly better (could be just chance)
>> than the LTS kernel I was using as control, under both good and bad
>> receiving conditions.
>> I'm still working on those graphs, expect them later today.
>>
>>
>>
>> On 16 November 2012 15:07, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>
>>> 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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121120/50052f22/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Graphs.tar.xz
Type: application/octet-stream
Size: 245760 bytes
Desc: not available
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121120/50052f22/attachment-0002.obj>


More information about the users mailing list