为什么ping这么慢？

我的设置：

地窖中的服务器+ GBit开关。长电缆到屋顶。GBit开关。我的屋顶上有三台电脑。一个只有100MBit以太网，一台带有GBit的笔记本电脑和一台新计算机。

从旧的100MBit计算机发出的Ping时间：平均为0.5ms从笔记本电脑发出的Ping时间：平均为0.4ms从我的新计算机发出的Ping时间：平均为5ms或30ms或200ms，但是我经常看到ping时间为980ms。通常，吞吐量非常不稳定。

我把屋顶的开关换了。没变。我更换了将新计算机连接到屋顶开关的电缆。没变。我安装了带有Intel GBit芯片（82541PI）的PCI网卡，并使用它代替了内置的Realtek RTL8111 / 8168B。没变。是的，我确定将电缆插入正确的端口，因为现在从DHCP服务器获得了另一个IP地址。

在使用相同操作系统（openSUSE 12.1）的旧计算机上，可以完全找到相同的网卡。

ifconfig 说：

      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:15679 errors:0 dropped:0 overruns:0 frame:0
      TX packets:13077 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 Sendewarteschlangenlänge:1000

ethtool 说：

    Speed: 1000Mb/s
    Duplex: Full
    Port: Twisted Pair

是什么导致这种现象？

[编辑]我发现了一些有趣的东西：

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        178          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    3302428          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1
 17:        184          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   snd_hda_intel
 23:      16721          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb2

如您所见，中断16服务于一个USB端口，图形卡“ mei”（？）和eth1。

我想这可以解释为什么它很慢。如何在2012年分配中断？

networking performance

— 亚伦·迪古拉（Aaron Digulla）
source

当您运行时ping，所有的ping命令都回来了吗？也就是说，您的setupu是否会释放ping或数据包？

— Bruce Ediger

我的数据包丢失了0％。太慢了可能是将错误的IRQ分配给了网卡？

— 亚伦·迪古拉

当您的Ping时间越来越长时，您是否同时监控了双方的CPU使用率以验证您是否不十分忙碌并导致调度程序延迟？

— Mike Pennington

您可以尝试将计算机彼此相邻移动，并使用短跨线连接它们。那应该排除由于开关不良，电缆长，沿途的电气干扰等造成的影响。是的，我知道，另一台计算机在该距离内也可以正常工作，但这可能是它对噪声信号或类似信号更能忍受的情况。

— MvG 2012年

在我的情况下，这是一台有故障的路由器，您可以像在此问题中那样找出来。

— 阿尔贝托·索尔维亚·诺维拉

我的主板是华硕P8Z77-M。BIOS版本为0802。此BIOS有一个错误：它将相同的IRQ（16）分配给所有可能导致各种问题的高吞吐量设备（例如，将文件复制到USB设备时冻结桌面）。

升级到版本1206可以改善这种情况。现在，网卡具有其自己的IRQ，并且ping时间现在应该在该时间：

64 bytes from ds.digulla (192.168.0.3): icmp_seq=1 ttl=64 time=0.197 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=2 ttl=64 time=0.252 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=3 ttl=64 time=0.200 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=4 ttl=64 time=0.239 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=5 ttl=64 time=0.215 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=6 ttl=64 time=0.204 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=7 ttl=64 time=0.244 ms
64 bytes from ds.digulla (192.168.0.3): icmp_seq=8 ttl=64 time=0.190 ms
^C
--- ds.digulla ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7001ms
rtt min/avg/max/mdev = 0.190/0.217/0.252/0.027 ms

— 亚伦·迪古拉（Aaron Digulla）
source