Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Thadeu Lima de Souza Cascardo <cascardo-DmMZpsCg3uxeGPcbtGPokg <at> public.gmane.org>
Subject: Re: [PATCH] rtl8187b: do not do per packet TX AGC
Newsgroups: gmane.linux.kernel.wireless.general
Date: Monday 30th August 2010 15:28:42 UTC (over 7 years ago)
On Mon, Aug 30, 2010 at 09:48:57AM -0500, Larry Finger wrote:
> On 08/30/2010 09:12 AM, John W. Linville wrote:
> > On Sat, Aug 28, 2010 at 04:32:48PM -0500, Larry Finger wrote:
> >> On 08/28/2010 12:54 AM, Thadeu Lima de Souza Cascardo wrote:
> >>> The code for rtl8187 does not do per packet TX AGC. Resetting the per
> >>> packet TX AGC for rtl8187b appears to increase its overall TX power.
> >>> This allows the device to associate and a connection be established
> >>> using APs a little further away.
> >>>
> >>> Tested-by: Thadeu Lima de Souza Cascardo

> >>> Signed-off-by: Thadeu Lima de Souza Cascardo

> >>> Cc: [email protected]
> >>> Cc: Larry Finger

> >>> Cc: Rogerio Luz Coelho

> >>> Cc: Herton Ronaldo Krzesinski

> >>> Cc: Hin-Tak Leung

> >>> ---
> >>
> >> I'm a little confused here. The subject says not to set the per packet
TX AGC,
> >> while the submission text says that setting it helps. I don't have
access to any
> >> documents that describe this register, but I expect that clearing
> >> RTL818X_TX_AGC_CTL_PERPACKET_GAIN_SHIFT would disable that feature. As
a result
> >> the code change seems to match the subject.
> >>
> >> I have not yet tested this code, but I do note that all the Realtek
drivers for
> >> the RTL8187B set this bit.
> >>
> >> Until testing, I withhold judgment on the actual code change, but NACK
for the
> >> inconsistency.
> > 
> > Perhaps the word "clearing" rather than "resetting" would be less
confusing?
> 

Thanks, John, for the clarification. Clearing is much better, really.

> I see the source of my confusion. I am in the habit of using lower case
to
> indicate the driver and upper case for the device. I would rewrite the
commit
> code to say "The code for the RTL8187L does not do per packet TX AGC.
Clearing
> the per packet TX AGC for RTL8187B ..."
> 

I will use your rewriting. Thanks.

> I have now tested the patch. For my RTL8187B device, I get the following:
> 
> Distance from AP      Indicated rate       Signal       Measured TX rate
>       2m                   18 Mb/s         -17 dBm      10 Mb/s
>      10m(original)         11 Mb/s         -48 dBm      2.6 Mb/s
>      10m(with patch)       11 Mb/s         -43 dBm      4.1 Mb/s
> 
> The measured TX rates were obtained using tcpperf. At a distance of 2 m,
the
> results were the same with and without the patch. At 10 m, the patch went
> through 2 exterior walls with drywall, insulation, and stucco. I'm not
sure that
> the increase from 2.6 to 4.1 Mb/s is reproducible. About all I can say is
that
> the change did not hurt the performance of the device, which is already
pretty bad.
> 
> If the OP can post numbers documenting the improvement, I have no
objection to
> this patch, even though every Realtek driver that I have seen turns "per
packet
> TX AGC" on for the RTL8187B and turns it off for the RTL8187L.
> 

Hum. Did you take a look at the version I've pointed out in the last
message, rtl8187B_linux_26.1056.1112.2009.release? It does not clear
PERPACKET_GAIN in the same function that it does for non-RTL8187B
devices. But it does in what should be the code for RTL8225Z2, in the
function r8180_rtl8225z2.c:InitializeExtraRegsOn8185.

I did not measure the distances exactly here, while doing my tests. But
I could move the AP further away by about 5 or 6 meters. The AP
indicated a -84dB signal while receiving injected packages. It was a
rt73usb device. File transmission through scp was not working that
further away, but I could still get an improvement of about 3 to 4
meters of distance.

I am still going to do some more testing today in a customer's facility.
And I would like very much that Rogério, who has reported some problems
too, did some testing.

> Larry

Best regards,
Cascardo.
 
CD: 3ms