Hi Anrea, Larry,
I used the new driver (still without the latest patches) only in hotels slow
DSL/Wireless environment and there I noted no regression.
Because of the problems I'am going now to a special site, where I have a local
networks (LAN/WLAN), good internet connection and root access to Linux
machines.
This should be a good thing to do real testing.
1.) Andrea, can you resend me the latest patches (perhaps against 3.16)
please?
(only to confirm that we are in "synchronous" mode.)
2.) Andrea, Larry, John are you interested to have root access to my laptop
using the rtl8187se?
(Perhaps it can stay there over the weekend too.)
3.) My test for maximal troughput is to run a connection /dev/zero -> nc ->|->
nc -> /dev/null.
Any other ideas?
4.) I think to have this setup ready about 11:30 UTC.
I'am open to any suggestion from your side.
Bernhard
Am Freitag, 12. September 2014, 02:18:03 schrieb Andrea Merello:
> My aplogies for this quick and a bit messy reply: I m from mobile.
>
> @Xose
> Thank you for forwarding me that. I wasn t aware of it.
>
> (BTW a couple of other people reported a similar issue)
>
> @Ralf
> The driver still have some not implemented features, including signal
> strenght measure, furthermore some fixes that might improve performances
> should be on the way for 3.17.
>
> @Larry, Bernhard
> I think those fixes was basically the same of some RFT patch I sent you
> some time ago..
> Have you had any occasion to test those patches?
>
> @Ralf, all..
> I must say that I never been able to reproduce any severe performance
> regression here, for this reason I'm asking people who reports this to make
> some testing for me if possible..
>
> Here you can find a similar report and my answer where I asked for the
> tests:
> https://bugzilla.kernel.org/show_bug.cgi?id=83631
>
> If you could do some of those test for me, that would be great.
>
> Because of the problems I'am going now to a special site, where I have a local
> networks (LAN/WLAN), good internet connection and root access to Linux
> machines.
> This should be a good thing to do real testing.
Excellent!
Thank you Bernhard!
> 1.) Andrea, can you resend me the latest patches (perhaps against 3.16)
> please?
> (only to confirm that we are in "synchronous" mode.)
Sure, I attach a cumulative patch, including all the changes I think
may matter (signal strength fix not included)
> 2.) Andrea, Larry, John are you interested to have root access to my laptop
> using the rtl8187se?
> (Perhaps it can stay there over the weekend too.)
Thank you for offering this :)
In case it turns out that you actually face performance regressions,
then it might help me to make some experiments using your machine.
I will do a register dump and I will try to tune some parameters in
the driver. This should NOT crash the machine, but if it is vital for
you that the machine remains alive, then maybe I will avoid at least
certain experiments..
Possibly tomorrow afternoon (Italian time) I will have some spare time
to work on this.
> 3.) My test for maximal troughput is to run a connection /dev/zero -> nc ->|->
> nc -> /dev/null.
> Any other ideas?
Usually I use two Linux hosts (the DUT and my production system) and I
use "iperf" program on both
On the production system (the iperf server) I run
iperf -s -u -b30M
On the DUT I run
iperf -c 192.168.1.2 -r -u -b30M
This will cause an UDP data exchange and will perform both downstream
and upstream throughput measurements.
I usually do this (at least) two times, and I discard results from the
first run, because rate selection algorithm might eventually need a
bit settle to a "good" rate.
> 4.) I think to have this setup ready about 11:30 UTC.
I was at my workplace, I really couldn't do quicker than this..
Sorry.. I hope we are still in time...
> I'am open to any suggestion from your side.
Tests that may also help are:
- test performance regression when you are both close to the AP and
enough far from it that performances significantly drops.
- check if the rtl818x_pci driver and the old driver settles at
(about) the same rates..
>
> Bernhard
Thank you really much Bernhard for you help.
I hope this can lead to solve issues, and anyway I appreciate it very much :)
Andrea
> Am Freitag, 12. September 2014, 02:18:03 schrieb Andrea Merello:
>> My aplogies for this quick and a bit messy reply: I m from mobile.
>>
>> @Xose
>> Thank you for forwarding me that. I wasn t aware of it.
>>
>> (BTW a couple of other people reported a similar issue)
>>
>> @Ralf
>> The driver still have some not implemented features, including signal
>> strenght measure, furthermore some fixes that might improve performances
>> should be on the way for 3.17.
>>
>> @Larry, Bernhard
>> I think those fixes was basically the same of some RFT patch I sent you
>> some time ago..
>> Have you had any occasion to test those patches?
>>
>> @Ralf, all..
>> I must say that I never been able to reproduce any severe performance
>> regression here, for this reason I'm asking people who reports this to make
>> some testing for me if possible..
>>
>> Here you can find a similar report and my answer where I asked for the
>> tests:
>> https://bugzilla.kernel.org/show_bug.cgi?id=83631
>>
>> If you could do some of those test for me, that would be great.
>>
>
On 09/12/2014 11:29 AM, Andrea Merello wrote:
>> Because of the problems I'am going now to a special site, where I have a local
>> networks (LAN/WLAN), good internet connection and root access to Linux
>> machines.
>> This should be a good thing to do real testing.
>
> Excellent!
> Thank you Bernhard!
>
>> 1.) Andrea, can you resend me the latest patches (perhaps against 3.16)
>> please?
>> (only to confirm that we are in "synchronous" mode.)
>
> Sure, I attach a cumulative patch, including all the changes I think
> may matter (signal strength fix not included)
>
>> 2.) Andrea, Larry, John are you interested to have root access to my laptop
>> using the rtl8187se?
>> (Perhaps it can stay there over the weekend too.)
>
> Thank you for offering this :)
> In case it turns out that you actually face performance regressions,
> then it might help me to make some experiments using your machine.
>
> I will do a register dump and I will try to tune some parameters in
> the driver. This should NOT crash the machine, but if it is vital for
> you that the machine remains alive, then maybe I will avoid at least
> certain experiments..
>
> Possibly tomorrow afternoon (Italian time) I will have some spare time
> to work on this.
>
>> 3.) My test for maximal troughput is to run a connection /dev/zero -> nc ->|->
>> nc -> /dev/null.
>> Any other ideas?
>
> Usually I use two Linux hosts (the DUT and my production system) and I
> use "iperf" program on both
> On the production system (the iperf server) I run
> iperf -s -u -b30M
> On the DUT I run
> iperf -c 192.168.1.2 -r -u -b30M
>
> This will cause an UDP data exchange and will perform both downstream
> and upstream throughput measurements.
> I usually do this (at least) two times, and I discard results from the
> first run, because rate selection algorithm might eventually need a
> bit settle to a "good" rate.
>
>> 4.) I think to have this setup ready about 11:30 UTC.
>
> I was at my workplace, I really couldn't do quicker than this..
> Sorry.. I hope we are still in time...
>
>> I'am open to any suggestion from your side.
>
> Tests that may also help are:
> - test performance regression when you are both close to the AP and
> enough far from it that performances significantly drops.
> - check if the rtl818x_pci driver and the old driver settles at
> (about) the same rates..
Hi,
I currently have a deadline to get some changes in rtlwifi into kernel 3.16,
thus I have no time for testing the RTL8187SE. I do know that the whole issue of
signal strength reporting for these chips is a problem.
Larry