Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've got a problem with my network speed. I sometimes have full download speed (i.e. 5 MB/s, which is about my max. internet dl-speed) and sometimes comparable slow speed (about 0.5 MB/s). This is affects both internet and home network!

When I got slow network speed it stays that way until I 'renew' the module for my PCI network card (sudo rmmod e1000 followed by sudo modprobe e1000). Then I've got full speed again for at least a few minutes, if I'm lucky even for a few hours...

I've got no idea where to look for such an error (and how to get rid of it). Any help/suggestion is appreciated!

EDIT2: 'Solution': I'm using a PCIe NIC now and everything works fine.

EDIT:

Xubuntu 12.10 (also tried other recent Distros like openSUSE and Fedora because of this issue, same results)

Kernel 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:18:20 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

ethtool eth0

Settings for eth0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  10baseT/Half 10baseT/Full 
                            100baseT/Half 100baseT/Full 
                            1000baseT/Full 
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: Twisted Pair
    PHYAD: 0
    Transceiver: internal
    Auto-negotiation: on
    MDI-X: Unknown
    Supports Wake-on: umbg
    Wake-on: g
    Current message level: 0x00000007 (7)
                           drv probe link
    Link detected: yes'

ethtool -S eth0

NIC statistics:
 rx_packets: 23955
 tx_packets: 19121
 rx_bytes: 23989358
 tx_bytes: 2096615
 rx_broadcast: 17
 tx_broadcast: 4
 rx_multicast: 556
 tx_multicast: 310
 rx_errors: 0
 tx_errors: 0
 tx_dropped: 0
 multicast: 556
 collisions: 0
 rx_length_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_no_buffer_count: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 tx_window_errors: 0
 tx_abort_late_coll: 0
 tx_deferred_ok: 0
 tx_single_coll_ok: 0
 tx_multi_coll_ok: 0
 tx_timeout_count: 0
 tx_restart_queue: 0
 rx_long_length_errors: 0
 rx_short_length_errors: 0
 rx_align_errors: 0
 tx_tcp_seg_good: 9
 tx_tcp_seg_failed: 0
 rx_flow_control_xon: 0
 rx_flow_control_xoff: 0
 tx_flow_control_xon: 0
 tx_flow_control_xoff: 0
 rx_long_byte_count: 23989358
 rx_csum_offload_good: 23035
 rx_csum_offload_errors: 0
 alloc_rx_buff_failed: 0
 tx_smbus: 0
 rx_smbus: 0
 dropped_smbus: 0

dmsg (partially, /var/log/kern.log says quite the same concerning e1000)

[12113.565834] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[12113.565838] e1000: Copyright (c) 1999-2006 Intel Corporation.
[12114.045957] e1000 0000:08:00.0: eth0: (PCI:33MHz:32-bit) 90:e2:ba:39:b1:17
[12114.045965] e1000 0000:08:00.0: eth0: Intel(R) PRO/1000 Network Connection
[12114.056047] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[12114.056399] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[12116.058691] e1000: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
[12116.059516] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[12245.684427] irq 18: nobody cared (try booting with the "irqpoll" option)
[12245.684432] Pid: 0, comm: swapper/2 Tainted: P           O 3.5.0-26-generic #42-Ubuntu
[12245.684433] Call Trace:
[12245.684435]  <IRQ>  [<ffffffff810e1c1d>] __report_bad_irq+0x3d/0xe0
[12245.684443]  [<ffffffff810e1f24>] note_interrupt+0x1b4/0x200
[12245.684448]  [<ffffffff810df6b7>] handle_irq_event_percpu+0xa7/0x1f0
[12245.684451]  [<ffffffff810df84e>] handle_irq_event+0x4e/0x80
[12245.684454]  [<ffffffff810e2a5a>] handle_fasteoi_irq+0x5a/0x100
[12245.684458]  [<ffffffff81015082>] handle_irq+0x22/0x40
[12245.684461]  [<ffffffff8168ad4a>] do_IRQ+0x5a/0xe0
[12245.684466]  [<ffffffff816812ea>] common_interrupt+0x6a/0x6a
[12245.684467]  <EOI>  [<ffffffff8139145a>] ? intel_idle+0xea/0x150
[12245.684474]  [<ffffffff8139143b>] ? intel_idle+0xcb/0x150
[12245.684479]  [<ffffffff81525009>] cpuidle_enter+0x19/0x20
[12245.684482]  [<ffffffff81525639>] cpuidle_idle_call+0xa9/0x240
[12245.684486]  [<ffffffff8101c48f>] cpu_idle+0xaf/0x120
[12245.684489]  [<ffffffff81669baa>] start_secondary+0x1de/0x1e5
[12245.684491] handlers:
[12245.684496] [<ffffffffa0148a60>] oxygen_interrupt [snd_oxygen_lib]
[12245.684501] [<ffffffffa0ae8540>] e1000_intr [e1000]
[12245.684502] Disabling IRQ #18

/proc/interrupts

       CPU0       CPU1       CPU2       CPU3       
  0:         43          0          0          0   IO-APIC-edge      timer
  1:          3          0          0          0   IO-APIC-edge      i8042
  8:          1          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          4          0          0          0   IO-APIC-edge      i8042
 16:     143514      62226     106210     312347   IO-APIC-fasteoi   ehci_hcd:usb1, nvidia
 17:        126          0          0         98   IO-APIC-fasteoi   snd_hda_intel
 18:        495      20639     179361     199518   IO-APIC-fasteoi   snd_oxygen_lib, eth0
 23:      30450     257271     182367     175510   IO-APIC-fasteoi   ehci_hcd:usb2
 41:          1          0          0          0   PCI-MSI-edge      xhci_hcd
 42:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 43:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 44:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 45:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 46:          1          0          0          0   PCI-MSI-edge      xhci_hcd
 47:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 48:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 49:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 50:          0          0          0          0   PCI-MSI-edge      xhci_hcd
 51:      40805       8429      38266      34073   PCI-MSI-edge      ahci
 52:          0          0          0          0   PCI-MSI-edge      ahci
 53:         11          0          0          0   PCI-MSI-edge      mei
NMI:        924        997        962       1005   Non-maskable interrupts
LOC:     895029    1172293     876204     941898   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:        924        997        962       1005   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RTR:          3          0          0          0   APIC ICR read retries
RES:     435704      55688      17924      11697   Rescheduling interrupts
CAL:      43826      56182      55976      43671   Function call interrupts
TLB:      24234      30699      30637      27213   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:         79         79         79         79   Machine check polls
ERR:          0
MIS:          0
share|improve this question
    
What do ethtool eth0 and ethtool -S eth0 tell you? Try also modprobe e1000 debug=16 and look for messages in /var/log/kern.log or dmesg. –  Stephane Chazelas Apr 2 '13 at 10:33
    
Thank you for your reply Stephane! I've added some files. I recognize an interrupt collision at IRQ #16. I once hat a performance issue with X because of nvidia occupying the same interrupt as eth0. So I switched slots and the problem was gone. But now? –  thw24 Apr 2 '13 at 12:08
    
@thw24 if you find the solutino please post your solution as an answer and accept it after 24h ;-) –  Kiwy Apr 3 at 10:49
add comment

2 Answers

I would hazard a guess that you have a loop in your switching network, which results in broadcasts, especially ARP-messages to never seize to travel your network. Over time, as more and more broadcasts are sent, your network becomes saturated with broadcasts so that there is hardly any (and ultimately none) capacitly left for your actual data.

As you can remmedy your problem by disabling your NIC, I'd guess your computer has more than one network interface (a WiFi device, maybe) and your computer closes the actual loop.

share|improve this answer
    
Good guess, I've added some file outputs. In BIOS I've deactivated my onboard network card so that's the only one. I also see a lot of rx and tx packets. –  thw24 Apr 2 '13 at 12:17
    
@thw24: There is always the chance the loop is somewhere else in your network wiring. Why are you using that NIC rather than your onboard NIC? Can you try using the onboard NIC instead of the other one? Check your cables and other devices. Maybe create a plan of your network topology? My money is still on the loop. –  Bananguin Apr 2 '13 at 18:09
    
The onboard NIC is broken, that's why I've deactivated it and use a PCI NIC now. Furthermore no other device is active in my network, I've changed cables, deactivated WiFi on the router and even plugged in my notebook and did some speed tests. Everything was fine except with my desktop system. My money is still on the IRQ handling (see below). :) –  thw24 Apr 2 '13 at 21:01
add comment

It might be a problem with the driver for the card. What kernel is this? Have you tried a newer version? Any bug reports for this card for your ditribution?

Do you have other machines connected to the network? Do they also see the slowdown? Try a LiveCD from the very last version of some distribution you are familiar with, and check if it also behaves this way.

If you run tcpdump(8) on the network for a while when it is "normal" and "slow", comparing traffic might smoke out something eating up bandwidth...

Update: With the logs, it is now clear that there is some issue with the kernel behind this. Update the kernel, and if this is the latest for your distribution report the above as a bug.

share|improve this answer
    
Thanks for your input vonbrand! I have the latest kernel (see EDIT). I even tried 13.04 (beta1). –  thw24 Apr 2 '13 at 12:27
    
Try an older kernel? I remember having strange issues with an e1000 too, that went away with a kernel update. Perhaps it is a (known?) regression? At least Fedora I believe would report this automatically... –  vonbrand Apr 2 '13 at 12:37
    
I've tried 3.5.0-17.28 which was shipped with Xubuntu 12.10. So not that old. I've also tried another NIC (with Realtek chip, r8169 afaik) that had/has the same problem. Maybe the IRQ thing that 'nobody cared'? ;) –  thw24 Apr 2 '13 at 12:49
    
Now that is strange... e1000 and r8169 have very little in common. Use another PCI slot? You have a tainted kernel (some "much better" nVidia driver, which is well known to mess up things?), get rid of that. The message suggests booting with irqpoll, have you tried that? –  vonbrand Apr 2 '13 at 15:26
    
I did try another PCI slot. The result: IRQ conflict with my video card that led to high cpu usage of X... And booting with irqpoll does not have any effect. And the recent kernel Ubuntu uses is tainted? As a matter of fact, any kernel I used so far, even 3.8.XX didn't change anything. –  thw24 Apr 2 '13 at 16:56
show 4 more comments

Your Answer

 
discard

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.