intermittent periods of packet loss and high latency

[Dan Candeto]

Intermittently and unpredictably, ping response times and packet loss will spike to unusable levels. Normal ping times are about .25 ms for other hosts on the local network, with essentially no packet loss. During the problematic periods (usually lasting 2-10 minutes), packet loss jumps to about 50% and ping response times on the packets that aren't dropped jump to between 250 and 750 ms.

This behavior started when I upgraded from Kubuntu 16.04 to Kubuntu 18.04. Changing which host on the network I test this with has no effect (and during this, those other hosts are able to use the network without any problem). Replacing the cable changes nothing. Using a different Ethernet interface changes nothing. Replacing the switch changes nothing. This is almost certainly not a hardware problem.

There is a chance that using wireless instead of Ethernet would fix the issue, but I have been avoiding that since the wired connection is much faster when Kubuntu is not malfunctioning.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: network-manager 1.10.6-2ubuntu1.1
ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
Uname: Linux 4.15.0-39-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Nov 20 12:48:05 2018
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2016-12-09 (711 days ago)
InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
IpRoute:
 default via [removed] dev enp0s31f6 proto dhcp metric 100
 169.254.0.0/16 dev enp0s31f6 scope link metric 1000
 [removed]/24 dev enp0s31f6 proto kernel scope link src [removed] metric 100
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to bionic on 2018-08-19 (92 days ago)
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 enp0s31f6 ethernet connected /org/freedesktop/NetworkManager/Devices/2 Wired connection 1 2e0d0ce3-8ee2-3c06-815d-eb9a42873b3b /org/freedesktop/NetworkManager/ActiveConnection/5
 [removed] bt disconnected /org/freedesktop/NetworkManager/Devices/5 -- -- --
 wlp3s0 wifi disconnected /org/freedesktop/NetworkManager/Devices/4 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.10.6 connected started full enabled enabled enabled enabled enabled
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: dan 2053 F.... pulseaudio
 /dev/snd/pcmC1D0c: dan 2053 F...m pulseaudio
 /dev/snd/controlC1: dan 2053 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=4eadd7fe-e046-471d-b0ee-f1c85365411e
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2016-12-09 (712 days ago)
InstallationMedia: Kubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
IpRoute:
 default via 192.168.4.1 dev enp0s31f6 proto dhcp metric 100
 169.254.0.0/16 dev enp0s31f6 scope link metric 1000
 192.168.4.0/24 dev enp0s31f6 proto kernel scope link src 192.168.4.42 metric 100
MachineType: Dell Inc. Precision Tower 3420
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
Package: network-manager 1.10.6-2ubuntu1.1
PackageArchitecture: amd64
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-39-generic root=UUID=89b1b98c-8c19-4200-966b-190a0ca44440 ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-39-generic N/A
 linux-backports-modules-4.15.0-39-generic N/A
 linux-firmware 1.173.2
Tags: bionic
Uname: Linux 4.15.0-39-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-08-19 (93 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo vboxusers
_MarkForUpload: True
dmi.bios.date: 08/17/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.11.1
dmi.board.name: 08K0X7
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.11.1:bd08/17/2018:svnDellInc.:pnPrecisionTower3420:pvr:rvnDellInc.:rn08K0X7:rvrA00:cvnDellInc.:ct3:cvr:
dmi.product.family: Precision
dmi.product.name: Precision Tower 3420
dmi.sys.vendor: Dell Inc.
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH
 enp0s31f6 ethernet connected /org/freedesktop/NetworkManager/Devices/2 Wired connection 1 2e0d0ce3-8ee2-3c06-815d-eb9a42873b3b /org/freedesktop/NetworkManager/ActiveConnection/5
 B0:48:1A:D8:81:FB bt disconnected /org/freedesktop/NetworkManager/Devices/5 -- -- --
 wlp3s0 wifi disconnected /org/freedesktop/NetworkManager/Devices/4 -- -- --
 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- -- --
nmcli-nm:
 RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN
 running 1.10.6 connected started full enabled enabled enabled enabled enabled

[Dan Candeto (dcandeto)]

Removed some identifying information from log files.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1804280

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

apport information

[Dan Candeto (dcandeto)]

This also occurs on wireless network connections, and *may* coincide with my USB mouse seeing lessened throughput.

It appears to be weakly correlated with the amount of load on the system. I see no evidence of it occurring at times when the system is not in use.

[Dan Candeto (dcandeto)]

Persists with 4.15.0-43-generic.

[Dan Candeto (dcandeto)]

Possibly the same issue as bug #1666432, but I can't confirm that it occurs on the wireless interface, just Ethernet interfaces.

[Dan Candeto (dcandeto)]

Persists on a freshly reinstalled system.

Output from ping -i6 [host] follows. Note the spike in ping time and high packet loss.

64 bytes from [host]: icmp_seq=3833 ttl=64 time=0.223 ms
64 bytes from [host]: icmp_seq=3834 ttl=64 time=0.212 ms
64 bytes from [host]: icmp_seq=3835 ttl=64 time=0.156 ms
64 bytes from [host]: icmp_seq=3836 ttl=64 time=0.347 ms
64 bytes from [host]: icmp_seq=3837 ttl=64 time=0.216 ms
64 bytes from [host]: icmp_seq=3838 ttl=64 time=0.316 ms
64 bytes from [host]: icmp_seq=3839 ttl=64 time=0.320 ms
64 bytes from [host]: icmp_seq=3840 ttl=64 time=0.168 ms
64 bytes from [host]: icmp_seq=3841 ttl=64 time=336 ms
64 bytes from [host]: icmp_seq=3843 ttl=64 time=216 ms
64 bytes from [host]: icmp_seq=3845 ttl=64 time=515 ms
64 bytes from [host]: icmp_seq=3846 ttl=64 time=423 ms
64 bytes from [host]: icmp_seq=3847 ttl=64 time=498 ms
64 bytes from [host]: icmp_seq=3849 ttl=64 time=569 ms
64 bytes from [host]: icmp_seq=3851 ttl=64 time=532 ms
64 bytes from [host]: icmp_seq=3853 ttl=64 time=496 ms
64 bytes from [host]: icmp_seq=3855 ttl=64 time=502 ms
64 bytes from [host]: icmp_seq=3857 ttl=64 time=424 ms
64 bytes from [host]: icmp_seq=3859 ttl=64 time=346 ms
64 bytes from [host]: icmp_seq=3861 ttl=64 time=352 ms
64 bytes from [host]: icmp_seq=3863 ttl=64 time=358 ms
64 bytes from [host]: icmp_seq=3865 ttl=64 time=573 ms
64 bytes from [host]: icmp_seq=3867 ttl=64 time=495 ms
64 bytes from [host]: icmp_seq=3869 ttl=64 time=627 ms
64 bytes from [host]: icmp_seq=3871 ttl=64 time=465 ms
64 bytes from [host]: icmp_seq=3873 ttl=64 time=261 ms
64 bytes from [host]: icmp_seq=3875 ttl=64 time=518 ms
64 bytes from [host]: icmp_seq=3877 ttl=64 time=440 ms
64 bytes from [host]: icmp_seq=3879 ttl=64 time=400 ms
64 bytes from [host]: icmp_seq=3881 ttl=64 time=410 ms
64 bytes from [host]: icmp_seq=3883 ttl=64 time=542 ms
64 bytes from [host]: icmp_seq=3885 ttl=64 time=338 ms
64 bytes from [host]: icmp_seq=3887 ttl=64 time=511 ms
64 bytes from [host]: icmp_seq=3889 ttl=64 time=475 ms
64 bytes from [host]: icmp_seq=3891 ttl=64 time=230 ms
64 bytes from [host]: icmp_seq=3893 ttl=64 time=571 ms
64 bytes from [host]: icmp_seq=3894 ttl=64 time=564 ms
64 bytes from [host]: icmp_seq=3896 ttl=64 time=598 ms
64 bytes from [host]: icmp_seq=3898 ttl=64 time=604 ms
64 bytes from [host]: icmp_seq=3900 ttl=64 time=317 ms
64 bytes from [host]: icmp_seq=3902 ttl=64 time=239 ms
64 bytes from [host]: icmp_seq=3904 ttl=64 time=538 ms
64 bytes from [host]: icmp_seq=3906 ttl=64 time=795 ms
64 bytes from [host]: icmp_seq=3907 ttl=64 time=453 ms
64 bytes from [host]: icmp_seq=3909 ttl=64 time=571 ms
64 bytes from [host]: icmp_seq=3911 ttl=64 time=535 ms
64 bytes from [host]: icmp_seq=3913 ttl=64 time=373 ms
64 bytes from [host]: icmp_seq=3915 ttl=64 time=463 ms
64 bytes from [host]: icmp_seq=3917 ttl=64 time=385 ms
64 bytes from [host]: icmp_seq=3919 ttl=64 time=265 ms
64 bytes from [host]: icmp_seq=3921 ttl=64 time=564 ms
64 bytes from [host]: icmp_seq=3923 ttl=64 time=444 ms
64 bytes from [host]: icmp_seq=3925 ttl=64 time=367 ms
64 bytes from [host]: icmp_seq=3927 ttl=64 time=0.123 ms
64 bytes from [host]: icmp_seq=3928 ttl=64 time=0.284 ms
64 bytes from [host]: i...

[Kai-Heng Feng (kaihengfeng)]

So this issue doesn't happen on v4.4 based kernel?

[Dan Candeto (dcandeto)]

I don't have a record of which kernel I was using under xenial, but I'm
almost certain that it was 4.4-based.

[Kai-Heng Feng (kaihengfeng)]

Is this same as LP: #1785171 and #1802691?

[Rondo5000 (lsdustin)]

I have been experiencing identical issues since around mid-January or so (though my latency sometimes reaches 3000/4000+ ms during these times). I am running a freshly installed and fully updated version of Ubuntu 18.04 Desktop. For the first couple of months after installing 18.04 I had none of these issues whatsoever, they seemed to materialize during a period when I was doing a lot of heavy software development which used a great deal of system resources (multiple VMs). Originally the workstation was wired directly to my router, but even after purchasing a wireless USB adapter I am still experiencing the issue.

I typically use remote viewing software to work on the affected workstation (from another laptop in my home), and once I begin to notice moderate sluggishness in the response time of the system I can typically run "sudo systemctl restart network-manager" and I will usually not begin to experience the issue again until several hours later, typically. If I go too long without running that command the full 10-15 minute period of extreme latency will set in. It doesn't return fully to "normal" response times after that high period, but it is far lower than the most extreme patches.

I hesitate to say that the issue is similar to other bug reports because of the "dropping of the connection" aspects of those. The connection never fully dies in this case, but just experiences periods of latency related unusability.

Any logs or further info available upon request.

[Dan Candeto (dcandeto)]

This could be the same issue as those other two.  Similar hardware is
involved.  I haven't had time to test changing those settings on the NIC.

On 2019-03-21 6:41 a.m., Kai-Heng Feng wrote:
> Is this same as LP: #1785171 and #1802691?
>

[Andrew (andrew-craucamp)]

I'm also affected by this bug. I'm using Wireless AC 5ghz on an Acer Spin 5 which apparently uses the Ath10k drivers if that's relevant. Ubuntu 18.04 is the most recent version of Ubuntu that I've confirmed to not be affected by this bug. I have tested every release thereafter (18.10, 19.04, 19.10) and every one of them has the "bouts of high latency" bug. I wrote a more detailed description of what I experience on Ask Ubuntu: https://askubuntu.com/questions/1144521/bouts-of-high-latency-over-wifi-with-steam-in-home-streaming

[Andrew (andrew-craucamp)]

At one point in my in-home streaming past I had to set the BSSID to my current router's IP address which resolved latency problems. I have multiple routers on my property with the same SSID, this is to provide wifi coverage to the entire property. I had to change the BSSID to the router I was using at any given time. Hopefully this is useful in some way.

[Dan Candeto (dcandeto)]

The problem continues with 4.15.0-65-generic. This is a ping summary coming into the affected system from another host on the same network segment with no connectivity problems, reflecting a four-minute period of recurrence (ping times were <1ms for the last 20 seconds or so, but while the problem was occurring, there was ~50% packet loss and >200ms response times for the packets that did get through):

--- [host] ping statistics ---
258 packets transmitted, 146 received, 43.4109% packet loss, time 259396ms
rtt min/avg/max/mdev = 0.109/377.848/641.641/190.332 ms

Note that network-manager has been purged from this system, so this is not a network-manager issue.

[Saren Taşçıyan (sarentasciyan)]

I can confirm same problem in 4.15.0-72-generic.

 *-network
                description: Wireless interface
                product: Wireless-AC 9260
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:05:00.0
                logical name: wlp5s0
                version: 29