Bug 1035376

FYI, Larry has volunteered to look after staging drivers for rtl stuff in Fedora before.  The repo you point too looks like one that is in prep for submitting the driver to staging.  Once it lands there, we can enable it if Larry thinks it's acceptable.

The situation with this driver is that I do not have an RTL8723AU card. For that reason, I am reluctant to make the changes needed to clean up the driver even for the staging tree. Without the ability to test, how would I know if I had created errors in the conversion. In particular, removing the typedef statements could be trouble.

A few months ago, someone offered to fix the checkpatch.pl errors, but I have heard nothing since then. I suspect that he underestimated the magnitude of the task.

I am willing to devote some effort to cleaning up the driver as long as someone is willing to test it.

The driver seems to be fairly solid - at least there are few reports of problems.

Larry,

I now have a laptop with one of these in it as of a few days ago (Lenovo
Yoga 13), so I will be willing to test.

Cheers,
Jes

I will be working on the driver and pushing the changes to http://github.com/lwfinger/rtl8723au.git. Please pull every day or so, and test. Please let me know if anything breaks.

I can't guarantee every day, but I shall try my best :)

Just hollor if there is anything noticeable that you want me to try out.

Larry,

One thing I am noticing is that the driver is extremely slow - I ran some very
unscientific testing here, running speed test using the 8723au vs a ralink
rt2800usb nano dongle.

Using the same external test server (I am on 100Mbit/sec FTTH here, so the
external link isn't the limit), I get the these speeds:

          Down           Up
8723au:    0.55Mbps/sec   1.24Mbps/sec
rt2800:   34.90Mbps/sec  42.00Mbps/sec

The speed differences are rather consistent between the two across multiple
runs.

[jes@yoga rtl8723au]$ sudo iwconfig 
[sudo] password for jes: 
wlp0s26u1u4i2  IEEE 802.11bgn  ESSID:"The Wilderness"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate:65 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=77/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[jes@yoga rtl8723au]$ sudo iwconfig 
wlp0s20u2  IEEE 802.11bgn  ESSID:"The Wilderness"  
          Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate=58.5 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=65/70  Signal level=-45 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:845  Invalid misc:25   Missed beacon:0


I am running this version of the driver:
commit 390e496b80b14d64b8f8701ad1354edff21b6689
Author: Larry Finger <Larry.Finger>
Date:   Sun Dec 1 00:00:28 2013 -0600

    rtl8723au: Remove C99 comments from core/rtw_xmit.c
    
    Signed-off-by: Larry Finger <Larry.Finger>

jes@yoga rtl8723au]$ uname -a
Linux yoga 3.11.6-301.fc20.x86_64 #1 SMP Mon Oct 21 21:54:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Unfortunately, that kind of situation will be hard to debug. First of all, if you issue the command 'git checkout c006177', is the performance better? If not, then use 'git checkout master' to restore the code. If it is better, then use git bisection to find the bad commit. Just in case you have not done that before, the sequence would be:

git bisect start
git bisect nad
git bisect good c006177

That will generate a trial version. Build it and test. Then 'git bisect <good,bad>' depending on the results. Let me know the bad commit.

If the bad performance was present in commit c006177, then checkout cd93a4a and see if it is better. That one is essentially the original code before I did much to it.

Larry

Larry,

I tried going back to cd93a4ae4151d69e9d198d8d4b3ef95c0e7714b6 (with
df02fe1aea27b9a3969d050a1853064f87308055 cherry-picked on top to allow for it
to build), but unfortunately the performance is just as bad.

Just to make sure, I also tried booting into 'that other OS' to make sure that
it wasn't a hardware issue, and there the performance is as expected.

Jes

Jes,

It seems that the performance problem is nothing that I did. I'll ask Realtek if they have any code changes that might address this situation.

Larry

(In reply to Jes Sorensen from comment #6)
 
>           Down           Up
> 8723au:    0.55Mbps/sec   1.24Mbps/sec
> rt2800:   34.90Mbps/sec  42.00Mbps/sec
> 
> The speed differences are rather consistent between the two across multiple
> runs.
> 
> [jes@yoga rtl8723au]$ sudo iwconfig 
> [sudo] password for jes: 
> wlp0s26u1u4i2  IEEE 802.11bgn  ESSID:"The Wilderness" 
> Nickname:"<WIFI@REALTEK>"
>           Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx:xx:xx:xx:xx
> 
>           Bit Rate:65 Mb/s   Sensitivity:0/0  
>           Retry:off   RTS thr:off   Fragment thr:off
>           Encryption key:****-****-****-****-****-****-****-****   Security
> mode:open
>           Power Management:off
>           Link Quality=100/100  Signal level=77/100  Noise level=0/100
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
> 
> [jes@yoga rtl8723au]$ sudo iwconfig 
> wlp0s20u2  IEEE 802.11bgn  ESSID:"The Wilderness"  
>           Mode:Managed  Frequency:2.462 GHz  Access Point: xx:xx:xx:xx:xx:xx
> 
>           Bit Rate=58.5 Mb/s   Tx-Power=20 dBm   
>           Retry  long limit:7   RTS thr:off   Fragment thr:off
>           Encryption key:off
>           Power Management:on
>           Link Quality=65/70  Signal level=-45 dBm  
>           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>           Tx excessive retries:845  Invalid misc:25   Missed beacon:0

Will state the obvious perhaps: 
A lot of excessive Tx retries on the 2nd one (assume that's is the rtl device?). 
Signal levels are acceptable but not great. If it's ok on "the other OS", wondering about firmware?  Tx retries will cause Tx rates to lower usually, and perhaps thrash, lowering throughput.  

Would love to get a Wireshark trace of that and see if it's missing acks from AP, causing the errors at the bottom listing (tx retries, invalid misc).
Anything interesting in dmesg?

>It's USB - I posted the iwconfig output in the BZ already (typing this
>from another box, so no copy-paste).
>Looks like the chip might be a combo WiFi+BT chip in one btw....

Might try turning of BT and see if throughput improves.. THey share antennas.

That might not be a problem. There is no driver for the BT part of the chip in the kernel. One has been proposed, but rejected by reviewers as duplicating too much of btusb.ko. The BT developers have incorporated a better means of handling the quirks of an individual device, but I have not yet found time to convert Realtek's version to fit the new structure.

On the other hand, if the OP has another BT interface that is active, the additional 2.4 GHz signals might be interfering.

I don't think the BT was the problem, after I removed the MP code, the
performance came back.

Sorry I patch bombed you a bit today - I hope the changes I sent you are
fine.

Plenty more to come.

Cheers,
Jes

Did you change CONFIG_MP_INCLUDED = y to "n" in Makefile, or was it some other change?

I'm working on the patch bomb. Thanks.

Larry

I found that a lot of places in the code had it hardwired and overruled the
config setting, so I simply ripped it out completely. I didn't think it was
needed in a normal driver anyway.

Jes

*** This bug has been marked as a duplicate of bug 1100162 ***