Vista多媒体播放和网络吞吐率
前段时间网上新出现了一条新闻，在Windows Vista中播放多媒体文件会导致网络性能降低。结果证明这个问题确实存在，但确实设计特性。今天看到Mark Russinovich（Windows领域的大牛，相信很多人对他都有不少的了解）的一篇Blog，对这个问题进行了比较合理的解释。
我翻译了这篇Blog，希望对英文不好的朋友有所帮助。当然，水平有限，翻译的内容难免会存在疏漏，还望大家指正。
通过这篇文章我们有什么体会？
1，对于百兆网络，或者只安装了一块网卡的电脑，完全不用担心这个问题
2，如果是千兆网络，或者有多块网卡，那么问题比较棘手。尤其是有多块网卡的百兆网络，希望相关的补丁能尽快发布。
3，看来那个售价超贵的“杀手级”游戏网卡还是有必要存在的。
下面是原文内容：
几周前，在2CPU 论坛由dloneranger发布的帖子介绍了在他的Vista系统中播放音频或视频文件时网络吞吐量降低的情况。其他人也提到自己遇到了同样的问题，同时上周大家的注意力被其他站点就同一个问题的讨论所吸引，包括Slashdot以及Zdnet博客Adrian Kingsley-Hughes。
很多人的推测是正确的，在播放多媒体文件时网络性能的降低确实是由于Multimedia Class Scheduler Service（MMCSS）服务的工作原理导致的，这是Windows Vista中的新功能，我在TechNet Magazine有关Windows Vista内核变化的一系列文章中进行过介绍。多媒体播放需要有一个恒定的媒体流传输速率，而如果无法满足这个要求，播放就会变得断断续续或不连贯。MMCSS服务由通用服务宿主进程Svchost.exe承载，并且要比音频和视频文件播放时的优先级更高，只有这样才能防止其他任务干涉播放软件对CPU的使用：
当一个多媒体应用程序开始播放的时候，改程序使用的多媒体API会调用MMCSS服务以提高播放线程的优先级为“实时”，这个范围内的优先级在16-31之间，在时间上对应每10ms的间隔内最多8ms，当然，具体还取决于播放线程需要多少CPU时钟周期。因为其他线程以动态优先级运行，往往是低于15的，因此哪怕是对CPU时钟周期需求很多的程序也不会干扰到播放。
要看到这个现象，你可以在Windows Media Player（WMP）中播放一个音频或视频剪辑，同时运行性能和可靠性监视器（开始-运行-Perfmon），选择性能监视器节点，在对象实例中为所有Wmplayer实例添加Priority Current计数器。随后将图表垂直比例的最大值设置为31（Windows上最高的优先级），随后你就能直接看到被提升了优先级的线程，如下图所示的21：
除了可能被其他线程影响外，媒体文件的播放还可能被网络活动所影响。当一个网络数据包到达系统后，会触发一个CPU中断，这将导致数据包到达的设备的驱动程序执行一个Interrupt Service Routine（ISR）操作。当这个ISR运行的时候，其他设备的中断会被临时阻止，因此ISR通常会进行设备book-keeping操作，然后用一个更耗时的操作将数据从收到的设备传输到启用了设备中断的延迟过程调用（Deferred Procedure Call，DPC）中。虽然DPC的执行是允许中断的，不过在运行了这些东西的处理器上，它的优先级要比其他任何线程还要高，无论线程的优先级是什么，这就有可能影响到播放媒体文件的线程。
网络DPC的接收操作是最“昂贵”的，因为这个过程中包括了将数据包传递给TCP/IP驱动的过程，而这个过程有可能导致很大的运算量。TCP/IP驱动会验证每个数据包，判断数据包所用的协议，更新连接状态，找到接收数据包的应用程序，然后将收到的数据复制到应用程序的缓冲中。下面的Process Explorer截图显示了当我从别的系统上复制大文件的时候用于DPC的CPU时钟周期是如何变化的：
在Vista的开发过程中对MMCSS的测试显示，就算有线程优先级提升（thread-priority boosting）功能，较重的网络通讯依然可能导致需要足够长时间执行的DPC妨碍到播放线程对多媒体文件的流畅播放，最终的播放结果可能会断断续续。因此MMCSS的“反停顿”机制被扩展为包含了对网络活动的调节。这个功能是通过给NDIS设备驱动天价了一个指令实现的，而NDIS是将网络适配器收到的数据包传输给TCP/IP驱动的主要组件，通过添加指令，NDIS每毫秒可以“标示”或者传递最多10个数据包（也就是每秒10000个）。
因为标准以太网Frame大小是1500字节左右，每秒将数据包数量限制为10000等于将网络吞吐率限制在最大15MB/s。百兆网络最多可以实现的吞吐量是12MB/s，因此如果你的系统在百兆网络中，你可能看不到任何影响。然而，如果你有千兆网络，而且发送端和你的Vista接收端都有千兆网络适配器，那么你的网络吞吐率会被降低到正常情况的15%。
然而NDIS调节功能的代码中很不幸有一个Bug，如果你有多个网卡，这会导致调节幅度被增大。例如，如果你的系统中同时安装了有线和无线网络适配器，NDIS每秒钟会处理最多8000个数据包；如果安装了三块网络适配器，每秒钟可以处理的数据包数量会降低到6000个。每秒6000个数据包等于9MB/s，这个结果甚至在百兆网络中的影响都是很明显的。
在一台安装了三个网络适配器的笔记本电脑上，我从其他系统中复制一个大文件，同时用WMP播放歌曲，借此让调节功能生效。下面的任务管理器截图显示了复制的吞吐量占用原本有大概20%，但是在开始播放歌曲的时候在千兆网络上降低到只有6%：
你可以在性能监视器中，在Network类别下添加“packets received per second”计数器来监控由NDIS收到的数据包数量。下图中，你可以看到收到的数据包数量的变化趋势和我上面提到的结果是完全一样的。NDIS处理的数据包数量并不满足理论上的最大6000个的结论，很可能是因为和远程系统握手的缘故。
尽管调节功能的限制程度如此之大，互联网通讯，哪怕最好的宽带连接都不会受到影响。那是因为在你的系统和互联网上其他系统之间的中间连接（intermediate connection）的多样性，以及传输的数据包片段可能降低数据包传输速度，因此对这类数据包的影响远不如系统传输数据时的影响大。
Vista使用的调解率的标准来自多次实验，并能确保在一颗CPU的百兆网络中保持尽可能高的数据包接受率的条件下防止播放过程产生停顿。这个硬性的限制对于当今的，具有多核高速CPU以及千兆网络的系统来说影响是很微弱的，而除了修复在安装了多个网络适配器上的系统中存在的Bug，我们的网络Team正在和MMCSS Team合作，希望将对网络速度的影响降到最低，但同时尽可能保证播放的流畅感受。
更多详细信息请关注我的Blog。