slow speed after rebooting from Windows

[jans23]

I'm using this driver with the latest Ubuntu since 10 months. It works pretty well. However, when I perform a reboot from Windows 8 and load Ubuntu, the wifi speed is pretty slow. The workaround is to shutoff and restart the computer instead of a soft reboot.

[lwfinger]

I passed your very useful observation to the driver developer. What branch of the repo are you using?

[jans23]

master branch. Thanks for taking care of this.

[lwfinger]

What kernel are you running? In particular, is it new enough to build the kernel_version branch? The two branches are running completely different drivers, and it would be instructive to know if the kernel driver also has this problem.

[jans23]

My kernel is 3.13.0-30-generic but I experienced the same issue during the last 10 months with various kernel versions.

[lwfinger]

That did not exactly answer my question. Does it help when you switch from the "master" to the "kernel_version" branch?

The developer has seen the reverse of this problem when booting from Linux into Windows. Have you seen that as well? In addition, please provide details on your connection. He needs the channel, bandwidth, and encryption method. In addition, the "iw scan" output would be useful.

[jans23]

Hi! I installed the driver using DKMS. Any quick instruction on how to update/change the module from "master" to "kernel_version"?

[lwfinger]

git checkout kernel_version

[jans23]

No, switching to kernel_version doesn't solve the issue for me.

[lwfinger]

Please provide the details about your connection that was mentioned 4 posts ago.

[jans23]

Sorry, I missed that earlier question. Its channel 1, bandwidth 72 Mb/s, encryption WPA2. Is the following scan what you need? See http://pastebin.com/kBRnVs47

[jans23]

When I boot from Linux to Windows, the wifi isn't working immediately. Usually I have to wait one or two minutes to get it up and running. Alternatively I can disable and enable the wifi via "airplane mode" button to get it up and running. In any case I don't experience any performance issue on Windows.

[lwfinger]

The scan is fine, but I did notice some problems in the setups of that set of APs. Wifi is not like TV where adjacent channels do not interfere. In wifi, the channels are spaced at 5 MHz, but each radio uses 20 MHz width for 802.11b/g, or 40 MHz for 802.11n. Looking at that list:

ESSID
some more questions: Which of the APs in the list is yours?

Do you control that AP? If so, could you temporarily run it without encryption to see if the slow-speed problem persists when you warm boot from Windows?

[lwfinger]

I hit the wrong key and posted before I was ready. Let me start again.

Wifi is not like TV where adjacent channels do not interfere. In wifi, the channels are spaced at 5 MHz, but each radio uses 20 MHz width for 802.11b/g, or 40 MHz for 802.11n. Once you do the math, for 802.11g, the non-interfering channels are 1, 6, and 11. Looking at the list you posted:

ESSID Channel Strength
Fritz The Cat 1 90
MAMA 1 19
WLAN-491E36 1 0
Dr.athlos 1 7
EasyBox-9E8A36 2 39
ALICE-WLAN46 4 23
o2-WLAN99 5 42
WLAN-38DA09 6 26
FRITZ!Box Fon WLAN 7141 6 10
WLAN-2D9B07 8 23
WLAN-A93D62 8 7
FRITZ!Box 6360 Cable 11 18
FRITZ!Box Fon WLAN 7270 10 56
catwalk 11 26

From the strength, I think your ESSID is "Fritz The Cat". If so, then your signal is being overlapped by the next 8 in the list. If possible, you might try switching your AP to channel 11. The spectrum is a bit quieter there.

If your ESSID is not "Fritz The Cat", please tell which one is yours.

If you control the AP, is it possible to temporarily switch encryption off and see if the problem of slow speed after a warm boot persists? Although unencrypted networks are a huge security risk, that will tell us if the encryption is a problem.

Another test that will help is to create (as root) a file name /etc/modprobe.d/50-r8723au.conf containing one line that contains "options r8723au debug=3". Then cold boot into Windows and warm boot back to Linux. After a few seconds, use the airplane mode switch. That debug option should yield additional messages in the dmesg log. Post the messages that follow the loading of r8723au, delete the file we created above, and unload/reload the driver (or reboot).

[jans23]

After a kernel update I experience a totally different behaviour of the driver. I strongly suspect that switching to "kernel_version" branch only got into effect when the new kernel was installed. Now, the behaviour is that after a resume of the system the wifi does either take several seconds or minutes to get reconnected, sometimes I have to disable and enable the wifi for several times and sometimes it only reconnects after a reboot of the system.

Unless you still need the previously instructed information, I would switch back to the properly working master branch. Please let me know how to proceed.

[stjoannou]

Confirming that I have the same issue. Using kernel_version with kernel 3.16.1. Restarted from Windows and did a speed test (from speedtest.net) and only got 2Mbits download but I got 4Mbits upload. After shutting down the starting normally I got 15Mbits download and 5Mbits upload which is more in line of what I should be having.

[lwfinger]

As I have neither a device nor do I run Windows, there is little I can do other than the unhelpful suggestion that you do not warm reboot from Windows. :)

One thing you might do is to use the usbmon facility in Linux to see if there is any difference in the traffic to/from the device in the two cases. A description of how to do this is shown at https://www.kernel.org/doc/Documentation/usb/usbmon.txt.

It will be a little tricky as the very first communication is likely to be critical. As a result, you will need to prevent the driver from loading until after the USB monitoring is started. If you save the USB monitor data to files and post those files, I might be able to see where there is a difference.

[midenok]

I confirm that this reproduces when restarting from Windows. Also the problem gets fixed after sleep mode:

echo -n mem >/sys/power/state

I also experience Windows problems after restarting from Linux.

The question is, why the state of card is not completely resetting after rebooting from Windows/Linux. If modern motherboards do not reinitialize hardware on warm boot, then drivers should do it. The fix may be to poweroff-poweron the device on Linux driver load/unload. Also, even if I believe that this is completely possible with scripts and sysfs, this probably should be implemented inside the driver itself. Possible, with configuration option reset_device.

[lwfinger]

We understand the principle - there is not need to lecture us. Remember, I do not have a device, nor do I ever run Windows, thus I have no chance of duplicating or fixing the problem.

On the other hand, you have both the device and the problem. You are in a much better place to create and test patches.

[lwfinger]

What part of "I cannot debug the device because I do not have one" do you not understand. I could throw in all kinds of resets and other crap code, and probably break the driver completely.

I provided the source in this GitHub repo as a courtesy to users. For this, I am repaid with this kind of vitriol. Should I delete the repo?

[TimboInSpace]

Don't delete the repo! It's the only thing that's made a linux installation feasible on my crappy Yoga13. I really appreciate that this was posted, thanks!!
I'm just glad I even found this post. Doing a cold boot takes an extra... quarter second?? I think that's a very good alternative.