这是设置：
>许多进程侦听不同的多播UDP流(5个多播
按进程监听)绑定在单个NIC上
>跨进程,所有多播使用相同的端口范围但不同的多播IP(重要的细节,因为给定端口的每个多播接收器将是REUSED服务器套接字的服务器)
>每个进程多播侦听带宽为10Mbits
>在NIC上设置RSS,在NIC& amp;上设置最大卸载设置. OS,MSI激活
行为：
> 17个以下的监听进程(大约85个加入UDP多播),内核
cpu影响是可以忽略的.
> 17岁至17岁之间22名听众(约110名加入
UDP多播),内核cpu使用率开始缓慢增长但是
接受
> 25以上,每个加入的组播开始产生巨大影响
在内核cpu时间内,这会影响所有RSS绑定的cpu
>每个侦听过程使用的cpu时间接近0(正常,因为进程除了读取多播之外什么都不做),所以真正的问题在于
操作系统组件
我们发现了什么：
>更改NIC硬件对行为没有影响(在HP NC382i上测试过,
基于Broadcom的NIC& HP NC365T,四核千兆,基于Intel)
>全局接收带宽不是限制因素(单个500Mbits流
不会触发cpu负载)
>阅读多播套接字似乎不是限制因素(我们
只使用dumb JOIN进行测试,只对多播流进行处理并重现cpu负载问题)
>拆分两个网卡上的多播流量似乎限制了cpu负载和传播
更好.但是,这不是我们的用例.
问题：
>我们至少需要能够收听大约500个组播流和
也许高达750
>相同的硬件,运行XP OS在cpu内核中没有此行为
时间
预期组件：
> NDIS.sys似乎是解释cpu使用量增加的一个很好的候选者.
有没有人遇到过这样的问题,可以给出一些调查方向.
我已经阅读了所有关于win server 2008网络性能增强的信息,但似乎都与TCP流量有关.
我还测试了可以通过registry或netsh命令完成的所有可能的优化.
除了调查您列出的不同硬件之外,您还可以扩展到10GigE,唯一的选择是使用代理服务器.
通过实验找到可以可靠管理的多个多播流,然后通过TCP将流转发到中央服务器或一组服务器.然后,该中央服务器可以使用TCP分段加速或完整ToE来使进入的网络负载对处理器无意义.
由于Windows驱动程序很差,我无法使用Broadcom硬件获得合适的多播速率.看看Linux如何在相同的硬件上运行会很有趣,这应该可以很好地指示硬件和IP堆栈的质量.
您将Windows XP列为正常工作,Windows Server和Windows XP之间的主要区别在于量子时间. Windows Server提供更长的量子时间,可能值得研究强制更短的量子(如果你甚至可以设置它).
