Bug 1127014 - Intel wireless powersave is too aggressive for Mumble
Summary: Intel wireless powersave is too aggressive for Mumble
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-wireless-iwl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-05 22:46 UTC by bztdlinux
Modified: 2015-04-28 19:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-04-28 19:04:00 UTC


Attachments (Terms of Use)

Description bztdlinux 2014-08-05 22:46:59 UTC
Description of problem:
Mumble uses high rate but low bandwidth UDP packets for communication. On wifi, I experienced constant dropouts of silence, where no packets would make it through.

I don't know if the powersave logic is in the kernel, or if it applies to wireless chipsets other than mine.

Version-Release number of selected component (if applicable):
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
kernel.x86_64                           3.15.7-200.fc20                            installed

How reproducible:
Always

Steps to Reproduce:
1. Connect to a Mumble server with an Intel wireless 7000-series adapter
2. Have one user talk
3. Observe audio cutting in and out
4. Run "iw dev xxxx set power_save off"
5. Observe audio working fine

Expected results:
Mumble works as expected, either with powersave mode on or off.

Comment 1 Justin M. Forbes 2014-11-13 16:03:37 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21.

If you experience different issues, please open a new bug report for those.

Comment 2 bztdlinux 2015-01-14 20:24:19 UTC
This still occurs with kernel 3.17.7-300.

I have also noticed that this affects HTTPS transfers - download speed increases nearly 50 fold when turning power safe off. It's bad enough that I would suggest turning power save off by default would be better than the current state of affairs.

Comment 3 John W. Linville 2015-01-15 14:39:36 UTC
Mumble might be able to set a socket option that helps this, dunno if they are or not.  OTOH, the iwlwifi firmware might be able to be less aggressive with its power saving.  Or...?  I'll Cc the Intel folks...

Comment 5 Emmanuel Grumbach 2015-01-15 14:52:19 UTC
This latency is inherent to WiFi.
WiFi comes with high latency in Rx when power save in enabled. Nothing we can do about that.
You can enabled uAPSD if you want. This was designed for that, but not every AP supports is well.

Comment 6 Emmanuel Grumbach 2015-01-18 08:57:22 UTC
BTW - what firmware are you using?

Comment 7 Emmanuel Grumbach 2015-01-18 08:58:11 UTC
You can also try to set the vif to low latency (in the iwlwifi debugfs dir of the interface).

Comment 8 bztdlinux 2015-01-24 04:45:42 UTC
I am using the stock firmware in Fedora 21.

A flag for low latency applications might be nice, because whatever control loop you have to control Rx on time won't be triggered by the low bandwidth. It seems that this is basically what uAPSD.

However, this is slowing down HTTPS transfers too, which are very high bandwidth. So I still think there is a bug in the driver or firmware at default settings.

Also, I'm using a Broadcom based AP for this test. I can also try with an Atheros one.

Comment 9 Emmanuel Grumbach 2015-01-24 19:16:56 UTC
Your first paragraph doesn't really parse. But basically, making power decision inside the driver is usually frowned upon in Linux... 
Regarding the HTTPS transfer, I don't really know what to say without any data. An external sniffer capture would be the least I need to debug this.

Comment 10 Fedora Kernel Team 2015-04-28 18:34:27 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.19.5-200.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22.

If you experience different issues, please open a new bug report for those.

Comment 11 bztdlinux 2015-04-28 19:04:00 UTC
This no longer occurs for me. I don't know if it was my upgrade to F22, or changes to my corporate wifi, but I'm going to assume it was fixed for now.


Note You need to log in before you can comment on or make changes to this bug.