WiFi Power Save

Help and Support Raspberry Pi
1

Recently I’ve been having problems streaming content into one of my 2 OSMC devices. It plays local files fine, but ones it streams over NFS (or through the BBC iPlayer kodi app) have been failing miserably - some fail to play at all and those which do play for only a few minutes before buffering.

The Pi concerned is an original model B+ with only 256MB RAM but was working surprisingly well until recently. Unfortunately due to it’s location in the house it has to be on wifi, but this has never caused it a problem before.

Using other devices in the same corner of the same room using wifi adapters with the same chipset I have ruled out NAS performance, NFS mount options and local wifi conditions as being the cause. This isn’t a kodi issue or an issue with the kodi NFS app as the NFS connection is managed by the kernel to a local mount point and kodi sees the files as if they were local.

The issue appears to be with the Pi’s network connection as exactly the same behaviour happens if I try cp /nfs/mount/point/myfile.avi /home/osmc/ - the maximum copy speed I achieve is 36kB/sec! Whereas with another machine in the same location I can get upwards of 600kB/sec and over a wired connection the NAS is capable of delivering upwards of 2MB/sec.

I’ve spend the best part of a week trying to fix this and followed various threads here and elsewhere and I keep coming back to one symptom as the most likely root cause, and this is the flooding of dmesg with the following (full dmesg here):

[  315.635791] IW_SCAN_THIS_ESSID, ssid=Booflenet, len=9
[  317.144056] survey done event(15) band:0 for wlan0
[  617.308713] IW_SCAN_THIS_ESSID, ssid=Booflenet, len=9
[  618.817542] survey done event(10) band:0 for wlan0
[  633.544553] rtl8192c_dm_RF_Saving(): RF_Save
[  653.547776] rtl8192c_dm_RF_Saving(): RF_Normal
[  719.548494] rtl8192c_dm_RF_Saving(): RF_Save
[  763.548835] rtl8192c_dm_RF_Saving(): RF_Normal
[  811.552539] rtl8192c_dm_RF_Saving(): RF_Save
[  887.555049] rtl8192c_dm_RF_Saving(): RF_Normal
[  918.876546] IW_SCAN_THIS_ESSID, ssid=Booflenet, len=9
[  920.360462] survey done event(17) band:0 for wlan0
[  955.558802] rtl8192c_dm_RF_Saving(): RF_Save
[  985.558795] rtl8192c_dm_RF_Saving(): RF_Normal
[ 1017.559979] rtl8192c_dm_RF_Saving(): RF_Save
[ 1220.411656] IW_SCAN_THIS_ESSID, ssid=Booflenet, len=9
[ 1221.920777] survey done event(18) band:0 for wlan0

It seems like the WiFi adapter is continually going to sleep and waking up, even when there is network traffic. I saw an answer here (and the same answer in several other threads) but this no longer works as iwconfig no longer seems to be shipped in OSMC and I’m hesitant to install it in case it interferes with connman.

The blog post announcing the August update does mention a change in the way some Realtek WiFi chips are managed due to a 5GHz connection issue, and I’m wondering if that has affected this, even though this is a different chipset, as this was not happening prior to that update. That said, it could simply be a coincidence or a corrupt file somewhere perhaps. The card itself is sane, I’ve run sudo fsck -fpv -C0 on both partitions and all was clean.

Has anyone come across a similar problem with this chip and resolved it?

2

A little more Googling and I have followed another thread to safely install iwconfig

Running it gave this error though:

osmc@boofleberrypi:~$ sudo iwconfig wlan0 power off
Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not permitted.

I’m starting to think that maybe my WiFi adapter may be due for replacement?

3

Just borrowed another WiFi dongle with the same RTL8188C_8192C chip which is working perfectly. Given that these are the same chip could it still be a software setting? Or do I definitely need a replacement adapter?

4

It’s not shipped to keep a minimal footprint; but won’t interfere with ConnMan, as it’s not a network manager.

Only 8812/21 was changed: 8192 chips don’t offer 5Ghz, so there is no change here for some time for your driver.

Try with iperf.

Check with lsmod on both adapters. If the same module is loaded for each adapter, then one of the adapters might be dodgy. Has it been dropped or knocked? The antenna wires are very small and can be damaged sometimes – although this doesn’t happen often.

5

Hi Sam, thanks for replying so quickly.

I wasn’t sure as Realtek chip numbers don’t always tally with the driver, the 8188 for example uses the 8192 driver. I don’t know when the issue started as the Pi plays local content perfectly only streaming content was a problem and it could have gone un-noticed for some time.

Both use the 8192cu module so I guess it isn’t software related. To be fair the adapter is a fair few years old and was a 99p special from eBay so maybe it’s just given up the ghost. To be honest given that the other one works I can’t see any other option now. Odd as nothing has happened to it and I would have expected it just to die if it were a physical issue, but you learn something new everyday.

Time to go shopping I think! :credit_card:

Looking at a Ralink 5370 this time with MIMO support, searching the forum I’ve seen people using them so I hope it will work out of the box.

6

Only 5Ghz chips use 8812, for definite.

Try shaking it (no joke)

Shameless plug, but if you want something that just works (with a warranty) and want the warm, fuzzy feeling of supporting OSMC ;), then check out Store - OSMC.

Sam

7

Hi Sam,

Can you confirm what chipset that uses? There is very little information in the product description.

8

It depends which dongle you choose.

802.11n varies: 7601
802.11ac is 7610U with a VID/PID change (we will work on tethering improvements for this in the future), and a longer antenna (internally) for better reception.

We don’t list the chipset because we reserve the right to change it in future iterations.

We also don’t want people to think the product is equivalent to another and end up disappointed (we had this problem with A2DP and some BT dongles).

9

It would be the 802.11n I’d be interested in as we don’t have any 5GHz kit so little point in paying out the extra.

I’m guessing the 7601 is a Realtek chip? Or is it a MediaTek?

10

It’s MT / Ralink (pre acquisition)

11

One month later the saga continues!

New official OSMC adapter arrived a little while ago and all has been well, no stuttering and no entries for

[  701.678657] rtl8192c_dm_RF_Saving(): RF_Save
[  751.678869] rtl8192c_dm_RF_Saving(): RF_Normal

in the log either.

This was the case on my normal Jarvis install and using the my test SD with a Krypton build on too. Using the Jarvis card it started stuttering again tonight - switched to the Krypton card and it improved a little but not much. Ran the logs and found endless entries of [ 701.678657] rtl8192c_dm_RF_Saving(): RF_Save again in dmesg.

Also noticed this:

20:04:22 3508.438232 T:3025838080 ERROR: DBus: Error org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files

I assume this means that Kodi is trying to display the “UnderPower” icon and can’t find the file, and on the assumption that my rather ancient PSU was starting to fail (and thus underdriving the WiFi adapter) I changed the meagre 1.0A supply for a new 2.0A one I had around. Stuttering improved but after a short while more [ 701.678657] rtl8192c_dm_RF_Saving(): RF_Save entries and the playback stuttered.

Now last time switching out the WiFi adapter solved the problem and I bought a new WiFi adapter (from the OSMC shop) but I can’t believe that one has failed already.

The new 2.0A power supply should definitely have enough power to power it as there are no other peripherals attached (and the UPower message has gone now).

I read in this thread that there is an option to compile the Realtek driver without powersave enabled, @sam_nazarko is the one that ships with OSMC compiled with power save enabled by any chance? If so is there a way of turning this off? (iwconfig shows PowerManagement:off already!)

That being said, I’m not sure why I’m getting any messages at all from the Realtek driver using the official OSMC dongle as it should be running on a MediaTek 7601…

If everyone who had an official OSMC WiFi adapter had this problem then the forum would be teaming so it must be something to do with my setup or a setting.

Any ideas? [Full logs here - http://paste.osmc.io/tesezetedu]

12

No – UPower is the replacement to HAL. This is just a failed attempt at enumeration by Kodi. It is in no way an error (search the forum for some background). We just don’t expose UPower fully with DBus.

You should actually see the UPower message in every Kodi.log.

Indeed – chuck the dongle in a PC or Mac if you can and see what happens :). If it’s still recognised, it’s not dead.

It sounds like your adapter isn’t dead, but rather you’re having some streaming issues with it? If it’s completely dead we can replace it in the post tomorrow morning. Can you clarify the exact issue?

Sam

13

Oh OK! Well a beefier power supply won’t hurt whilst I try and see what the problem is anyway…

No it’s not dead - it’s working very well for the most part. The only problem I have is the same as the problem I started the thread with originally:

Despite iwconfig saying PowerManagement:off my log is full of entries like this:

[  701.678657] rtl8192c_dm_RF_Saving(): RF_Save
[  751.678869] rtl8192c_dm_RF_Saving(): RF_Normal

and when it goes into power save streaming media over my /etc/fstab mounted NFS share stutters.

It all boils down to two questions really:

  1. If the dongle is using an MT7601 chip, why is my RPi using the Realtek 8192c driver?
  2. If PowerManagement is off then why is my log suddenly full of entries of the adapter going to sleep during streaming?

This only started today, you can see in the log I posted that there are no power save entries at all on the 16th October when I last used the Krypton card.

14

Are you on the staging or Krypton repository?

Can you show me output of /etc/apt/sources.list?

Sam

15

Happens exactly the same with both my normal standard Jarvis install and the one on the Krypton repository. Both SD cards have the same issue.

16

Jarvis card has the following repositories:

$ cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian jessie main contrib non-free
deb http://apt.osmc.tv jessie main

Krypton card has:

$ cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian jessie main contrib non-free
deb http://apt.osmc.tv jessie main
deb http://apt.osmc.tv krypton main

I’ve managed to stop the stuttering (even on HD!) by restarting my RPi2 which is the source of the NFS mount but I’m still getting the [ower saving messages in dmesg.

This leaves some un-answered questions:

  1. Why is the official OSMC dongle using the Realtek driver if it is supposedly an MT7601 chip?
  2. Is the Realtek driver shipped by OSMC compiled with powersaving disabled (as indicated by iwconfig)

I tried (for completeness) running up an Xbian install on a spare sd card. No power saving messaged in dmesg on there. Are they using a version of the driver compiled with powersave off? Or are they just supressing the messages from dmesg somehow?

17

Hi Gavin,

Thanks for the information.

The official dongle shipped by OSMC varies in the 802.11n form.

  1. The official dongle shipped by OSMC varies in the 802.11n form

I meant (usually) 7601. The 802.11ac variant is always 7610u at the time of writing. If you bought it from us, it should work well. I have made some driver changes recently, so I will see if that’s causing any issues

I will produce a new kernel with some improvements if you are willing to try it.

Regarding XBian: I believe they still use Upstart instead of systemd, which may log kernel messages in a different way, and they may have a different loglevel which shows fewer kernel messages. It would also be interesting to know which kernel version they ran. They may be using the in-tree driver, although this can have some problems of its own. I’d be interested in knowing if the dongle ran better on XBian.

Cheers

Sam

18

Hi @sam_nazarko thanks for clarifying details about the dongle, that certainly explains why I can see Realtek messages in the logs.

Regarding seeing the issue in Xbian it isn’t quite as simple as I thought, and neither is it as reproducible in OSMC as I thought.

It seems that what is happening is as follows:

Pi1 is client with OSMC and WiFi dongle.
Pi2 is server with OSMC, NFS server, wired.

  1. Pi1 makes connection with Pi2 for both NFS streams and MySQL.
  2. Pi1 WiFi goes to sleep.
  3. Pi2 drops connections from ESTABLISHED to TIME_WAIT
  4. Pi1 WiFi wakes up.
  5. Pi1 makes new connections to Pi2 (leaving original connections in TIME_WAIT)
  6. GoTo 2.
  7. Eventually TIME_WAIT connections build to such a level that new connections take too long to establish and the connection stutters.

In the end reatarting Pi2 restored service by killing hundreds of TIME_WAIT connections that had built up. If I’m right replication will take many days each time.

Really appreciate you looking into the kernel though, happy to test on my Pi1 when ever you’re ready. I’ve been googling around the power management issue amd it seems that the Realktek driver ignores any userland changes and instead must be compiled with power management on or off and this can only be changed at compile time. I’m guessing from your message that at some point this ceased to be the case? Upstream change?

19

OSMC has its own rtl drivers for most adapters, and this adapter is one of them. This allows us to track changes more effectively and carry some improvements downstream in relying on upstream drivers which lag behind.

WiFi power saving has been disabled since July 2015. Upon further inspection, it looks like potential preamble issues with registers being set when this may not be beneficial.

I’ll let you know when something’s ready for testing.

1 Like
20

Hi Gavin,

I’ve made a new kernel available. I’ve pinged you in Slack.