On one of my linux computers the network is acting weird. It's really slow when connecting to any computer outside of my local network (~1.5 Kb/s no matter what server). At the same time it has good speed within the local network (>4 Mb/s).
Dmesg does not report any errors related to the loaded module, dns is working, the mtu-size is fine. I'm using a wired connection, not wlan. I have tried with different cables and different ports on the router, the problem persists.
Some statistics:
ip -s -s link
eth0 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
161453 227 49 0 0 0
RX errors: length crc frame fifo missed
0 0 0 49 109
Tx has no errors.
ethtool says:
ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
ethtool -S eth0
NIC statistics:
tx_ok: 17330
rx_ok: 24344
tx_err: 0
rx_err: 0
rx_fifo: 1034
frame_align: 0
tx_ok_1col: 0
tx_ok_mcol: 0
rx_ok_phys: 24295
rx_ok_bcast: 49
rx_ok_mcast: 0
tx_abort: 0
tx_underrun: 0
rx_frags: 0
Ok, so I just proxied the traffic through another local machine and managed to get xorg, firefox etc down and I just realized that:
So it seems that it's related to having FEW active connections (I also get a higher degree of fifo errors when having one single connection). Could this be a driver issue?
1.5Kb/s is the right size for one packet a second. I've seen cases where the TCP Delayed Ack wasn't working and packets were getting sent with 200ms delays, but 1000ms is something else entirely. This is the point where I'd break out the packet sniffer and see what's happening on the wire.
Since you are seeing different behavior from on-network and off-network traffic, I'd grab captures in three areas:
2 and 3 are very important, since it can help you figure out if your border device is somehow filtering things it shouldn't be or if the remote side is doing things it shouldn't. You're looking for anomalies, and as there are a large number of ways things can fail this way I can't give you specific guidance on how to identify things that are there. Wireshark has some very good error-highlighting, which may tell you what's going on just by loading the captures.
Reasons for slowness could be:
NIC duplex and speed incompatibilities
Bad cabling
Electrical interference
What does ethtool eth0
(run as root) show you? Compare this with another PC. ethtool -S eth0
shows a more detailed error report.
User contributions licensed under CC BY-SA 3.0