Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

  1. If I load a heavyweight webpage everything behaves as expected, speed is fine
  2. If I only wget a single file, with no other tcp-connections running, the behaviour persists

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?

share|improve this question
I'd say a driver issue too. If you'd disclose the first 3 bytes of the ethernet address, I would recognize the board type and could for driver issues. – ott-- Nov 6 '11 at 19:43

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:

  1. Local-to-Local traffic
  2. Local-to-Remote traffic, inside your border device (such as at the local server itself via TCPDump)
  3. Local-to-Remote traffic, outside your border device (good: on the border device itself, better: on the switch that feeds the border device's internet connection).

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.

share|improve this answer
Well, I'm looking at some dumps now. The only thing I can see so far is that I loose some segments (both on-network and off-network) and that at some points it takes ~700 ms between me sending an ACK and receiving the next data. Do you know what the "fifo" and "missed" errors mean? Any ideas of specific things to look are welcome – lode Nov 5 '11 at 18:52
@lode Sounds like you're getting packet drops, which is causing re-transmits. That kind of thing can really torpedo throughput because of the timeouts. Verifying cabling like ott-- mentioned would be good. "missed" is sometimes caused by the TCP stack dropping the packet for load reasons. You can get around that by using a span or mirror port on your switch and capturing by way of another device. – sysadmin1138 Nov 5 '11 at 19:27
Well, yes. I tried switching cables. Unfortunately I don't have a mirror port. At the moment there is no load on this computer so I still haven't found an explanation. I updated the questions with more info if you have time to look at it. – lode Nov 6 '11 at 15:30

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.

share|improve this answer
I updated the question with new information – lode Nov 6 '11 at 10:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.