Bug 183321 - iwlwifi: 8260: high latency and package loss even with 11n disabled - WIFILNX-112
Summary: iwlwifi: 8260: high latency and package loss even with 11n disabled - WIFILNX...
Status: CLOSED DOCUMENTED
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: DO NOT USE - assign "network-wireless-intel" component instead
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-26 06:05 UTC by Tobias Schmetzer
Modified: 2017-01-09 15:58 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.8.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Two manual iwldumps a couple of seconds right after seeing the latency going up (2.47 MB, application/zip)
2016-10-26 06:05 UTC, Tobias Schmetzer
Details

Description Tobias Schmetzer 2016-10-26 06:05:26 UTC
Created attachment 242791 [details]
Two manual iwldumps a couple of seconds right after seeing the latency going up

Dear wifi-team,

sometimes (not always but a lot of times) I have serious trouble with my connection to the router and therefore accessing the internet even when using the workarounds (BT not used, 40 Ghz disabled, 11n disabled).

I had problems with firmware crashes due to TFD queue hang (see discussion at bug report https://bugzilla.kernel.org/show_bug.cgi?id=173101) but this seems to be a different problem.

Apart from having a slower performance when using the workaround, I do also have a bad connection with high latency and remarkable packet loss paired with almost no data coming through right after opening a connection like an arbitrary website. The firmware doesn't crash though and there's no problem reported in syslog. 

Example ping to my router:
64 bytes from 192.168.0.1: icmp_seq=584 ttl=64 time=16.9 ms
64 bytes from 192.168.0.1: icmp_seq=585 ttl=64 time=81.5 ms
64 bytes from 192.168.0.1: icmp_seq=587 ttl=64 time=98.3 ms
64 bytes from 192.168.0.1: icmp_seq=588 ttl=64 time=876 ms
64 bytes from 192.168.0.1: icmp_seq=590 ttl=64 time=9188 ms
64 bytes from 192.168.0.1: icmp_seq=604 ttl=64 time=8486 ms
64 bytes from 192.168.0.1: icmp_seq=606 ttl=64 time=8694 ms
64 bytes from 192.168.0.1: icmp_seq=608 ttl=64 time=8112 ms

>ethtool -i wlp1s0 | grep firmware
firmware-version: 22.391740.0
(Debug-Version)

>uname -a 
Linux camilo 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:03:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

>lspci -v
01:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
	Subsystem: Intel Corporation Wireless 8260
	Flags: bus master, fast devsel, latency 0, IRQ 129
	Memory at a5000000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number e4-b3-18-ff-ff-b1-c6-9b
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [154] L1 PM Substates
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

I append two encrypted manual iwldumps. If you can't find anything special going on there I'm happy try a special latency sensitive debug version of the firmware.
Comment 1 Tobias Schmetzer 2016-11-22 21:49:30 UTC
The connection is really very slow and not acceptable. As this is meant to be a workaround for bug 173101 but doesn't work well either, I am going to rise importance. I hope the problem can be solved with software in time and there's no hardware bug involved.

Interesting thing is that the windows driver seems to have major trouble in this situation as well. On windows I couldn't get a Wifi connection at all!

Is there anything else I can do to support a quicker analysis of the problem?
Comment 2 Luca Coelho 2016-11-25 07:30:38 UTC
Thanks, Tobias! I'm opening an internal bug report for tracking this.  Thanks for the dumps, we'll take a look at them and see if we need any more information.  I'll come back to you soon.
Comment 3 Tobias Schmetzer 2016-12-03 16:25:03 UTC
After becoming desperate I was about to buy a new WLAN USB stick. 
Before doing this I tried some more things and what I found out was that it is not an interference problem, but a direction problem. I most of the time used the wifi with my laptop lid closed and an external monitor, mouse and keyboard plugged in and got download speeds of 1 mbps (speedtest) and latencies between 1000ms and 15000ms while performing downloads.
When opening the lid (display) I get 20 mbps and latencies of only 100ms and 250ms. Everything on the internet is responsive now, which it did't use to be. The external monitor itself with its cable did not have any influence on the data rate.

So this is the simple final solution! I will use my laptop with open lid from now on with the need to protect the internal keyboard from dust and dirt. Why did the engineers put the wifi antenna into a place where it can be used in only one direction? :(
Sorry for the hassle of this kind of really obvious problem! Would it make any sense to put the recommendation of varying the antenna direction, together with the hint that some antennas are integrated in the lid, onto the interference webpage?
Comment 4 Emmanuel Grumbach 2016-12-03 17:27:52 UTC
Thanks Tobias. These kind of tests are always instructive. Indeed, people (including us) seem to forget too often, that WiFi is ... radio and that a very small change in the position of the lid which typically includes the antenna can have a dramatic effect.

I just updated the wiki.

Thanks!
Comment 5 Luca Coelho 2017-01-09 15:58:03 UTC
Closing this bug, since the problem turned out to be the position of the antenna. :)

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