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.
*********** 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.
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.
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...
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.
BTW - what firmware are you using?
You can also try to set the vif to low latency (in the iwlwifi debugfs dir of the interface).
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.
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.
*********** 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.
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.