2

Excluding this, as I have tried all methods listed on this site. And excluding this and this, they are in the aforementioned site. What are possible causes for a software based slowdown of internet.

Symptoms:

  • Booting in Windows or other live-boot disk makes Internet work, pings anything 0% loss.
  • Router can be pinged by the PC in question, while running Ubuntu, with 0% loss as well as anything in the same network 0% loss.
  • Pinging or mtr, by the PC in question to anything outside the network(on the other side of the router) results in 100% loss.
  • If the Router or other devices on the network try to ping the computer in question, they have 80% to 95% loss.

What could possibly be the cause of this kind of network failure on Ubuntu?

Ubuntu PCs with this problem have responses to lspci -knn | grep Eth -A2:

02:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8131 Gigabit Ethernet [1969:1063] (rev c0)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7599]
    Kernel driver in use: atl1c

This one has under 80% loss ~50% using a USB to Cat5 network port

00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Kernel driver in use: ehci-pci
Community
  • 1
Luke Burgess
  • 36
  • 8

2 Answers2

2

This is and always will be a will guess without being on-site, but there here are some reasons that might prevent Ethernet to function properly. Windows driver for the card might be able to do some automagic to degrade the settings of your card. Or the card needs some poke to do the autonegotiation.

  1. The most obvious might be duplicate MAC addressed. List the MAC addresses on the affected PC, then shut it down and then try arping the MAC addresses from different machine.

  2. Your router might be a real deal and block some default IP settings. If you could try using some other generic router on the network, then do so to rule out this possibility.

  3. Crooked or old cabling that prevent the card to function at higher speeds. You might try setting the link mode to 10M or 100M manually using either mii-tool or ethtool.

  4. Similar with full-duplex or half-duplex settings on the card.

Here's an article on mii-tool/ethtool that goes there in more detail.

One more idea how to debug the issue:

  • You can try sniffing the network interface using tcpdump or wireshark and observe the differences between pings initiated at the PC in question and pings initiated elsewhere.
  • The same can be done on the router if it's f.e. running embedded Linux, or you can plug a "sniffer" consisting of two network cards bridged together between router and the inside network.
oerdnj
  • 7,940
2

Another tool that you might want to employ is iperf. You can use this to determine if the local networking is killing your throughput. A reference is located at: https://iperf.fr/. You can simply generate high bandwidth loads and then check what that actual reported throughput is. If you have two nodes you can do the following check. First run

sudo lshw -c network

on both machines. Find your interface and note the reported link speed, should be something of the form:

size: 100Mbit/s
capacity: 100Mbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation

This interface reports 100Mbit/s, check this on both devices and determine the minimum you expect. Next use iperf to push a large ammount of traffic to determine what the actual throughput is

On node 1 run:

iperf -s -i 2

On node 2 run:

iperf -n 1000M -i 2 -c <SERVER IP>

This will generate a report on the client side of the form:

------------------------------------------------------------
Client connecting to <SERVER IP>, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local <CLIENT IP> port 36114 connected with <SERVER IP> port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 2.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  2.0- 4.0 sec  22.2 MBytes  93.3 Mbits/sec
[  3]  4.0- 6.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  6.0- 8.0 sec  22.4 MBytes  93.8 Mbits/sec

and something similar on the server side (the -s node). You'll note that in this case the throughput is pretty close to the reported ideal. You should expect to loose a couple of Mbits/sec to TCP overhead, but if this value is far off, you can blame something inside your network. If this number is within some tolerance (say 5-7% of reported), you're problem lies beyond your gateway.

At that point one can ask if your service provider is proxing, or doing some flavor of traffic shaping that gives preferential treatment to certain types of traffic?

James S.
  • 121