我试图使用旧的富士通RX300S2，四核英特尔®至强®CPU @ 2.80GHz作为Gitabit NAT路由器，它具有通过PCI-X的双千兆网卡。
路由器也会将来自外部接口的组播stream量转发到内部networking。 组播路由由上游Cisco路由器处理，所以NAT路由器只需要“泄漏”eth1（上游）和eth0（内部）之间的组播stream量。
这已经使用igmpproxy正确设置，基本上使L3路由器根据组播stream量作为L2桥。
在testing吞吐量时，在200个组/stream（大约80,000 p / s）上接收大约850-900Mbit的组播stream量给用户空间中的本地进程是没有问题的，它也实时分析200个stream而不丢包。 本地进程最高可达100％。
这些stream由封装在IP UDP数据包中的IPTV mpeg传输stream组成。 7×188 = 1316字节的有效载荷。
但是当在转发模式下testing吞吐量时，例如，组播stream量进入eth1，并在内核级别路由到eth0并发送到本地networking时，NAT路由器不能转发所有收到的stream量。
外部接口eth1接收所有组播stream量〜900Mbit，但出接口只发送〜600Mbit，并且根据eth0附接的接收testing机，所有stream受到丢包的影响。
当分析负载ksoftirqd / 3在100％的CPU上达到最大值，而其他3个核心在10％以下时，看起来不是所有4个内核都参与负载。
/ proc / interrupts也显示eth0和eth1共享irq16：
CPU0 CPU1 CPU2 CPU3 16: 0 0 92155 208280892 IO-APIC 16-fasteoi uhci_hcd:usb2, uhci_hcd:usb5, eth1, eth0 可以看出，CPU3处理不成比例的中断。
我已阅读了有关cpu_affinity的各种文本，并尝试将CPU内核固定到networking队列中。 不幸的是，这个来自Broadcom的NIC tg3不支持多个队列，但是仍然应该可以在这个四核系统上的更多核心之间共享负载。
或者是PCI-X总线是瓶颈，但是如果是这样的话，那么在传入的eth1和传出的eth0上的吞吐量应该被减less，并且数据包应该被eth1丢弃， 但是看起来在eth1和eth0之间丢失了数据包。 不正确，因为在路由器中丢失数据包时，/ sys / class / net / eth1 / statistics / rx_missed_errors增加很多（大约1000 p / s）。
当只有100个通道和大约500Mbit的数据包转发时，丢包不会发生，ksoftirqd / 3只占CPU的5-6％左右。 但是当600Mbit被转发时，ksoftirqd / 3消耗100％，所以似乎在CPU之外的一些瓶颈被击中。
难道这样的旧服务器只能在两个内置网卡之间向一个方向转发1Gbit的UDPstream量吗？ 即使数据包很大，1316字节的有效载荷，在1Gbit中给出了适中的80..90kp / s？
我们放弃了服务器，按规定，两个板载networking接口不应该驱动全千兆位的stream量。 第二个界面缩进来用于pipe理。
带有PCIe和两个Intel i210千兆位适配器的标准桌面核心i5能够转发1Gbit多播UDPstream量，没有任何问题。
虽然，由于stream量突发，它需要调整RX和TX缓冲区（ethtool -G）。 2倍或4倍速PCIe可能有助于降低由于PCIe总线拥塞导致丢失数据包的风险。