NIC 数据包传输不一致、NIC 性能测量
我们的一位客户在使用我们的流应用程序 (win32) 时遇到问题。看起来应该由应用程序以某个恒定间隔（例如 20 毫秒）发送的 UDP (RTP) 数据包实际上是用变化很大的增量（例如 15 毫秒 - 25 毫秒 - 10 毫秒 - 30 毫秒）发送的。这是唯一遇到此问题的客户，因此网卡或其他操作系统网络相关基础设施是我们的首要怀疑。
问题是什么样的网络配置可能会引入此类问题（AV？，QOS？）
以及如何测量实际调用“发送”功能和数据包实际传递到网络之间的时间？有没有可用的工具。
One of our customers experiences problem with our streaming application (win32). It seems like UDP (RTP) packets that should be sent by the application with some constant interval (say 20 ms) are actually sent with a greatly variable deltas (say 15ms - 25ms - 10ms - 30 ms). This is the only customer that experiences the problem so network card or other OS network related infrastructure is our primal suspect.
The question is what kind of network configuration may introduce such problem (AV?,QOS?)
And how can I measure the time between actually calling "send" function and the moment the packet was actually delivered to the network? Is there any tool available for it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我怀疑任何网络问题都可能导致此问题。
基本 UDP 没有 QoS（服务质量）概念（甚至可能会丢失数据包、出现重复数据包等）。您的网卡必须对数据包进行排队才能写入网络，因此您无法保证传输，因为它对来自不同应用程序的数据包进行排队。
路由器也可以确定优先级，这将影响这些数据包的规律性。
编辑：您已经指出了本地网卡，所以上面的内容。路由器不适用于这种情况。
简而言之，没有任何理由认为上述内容是不可接受的。
I suspect any network issue can cause this problem.
There's no concept of QoS (quality of service) with basic UDP (even to the point that you can lose packets, have duplicates etc.). Your network card has to queue up packets to write to the network, and so you can't guarantee deliveries since it's queueing up packets from different applications.
Routers can prioritise as well, and that will affect the regularity of these packets.
EDIT: You've pointed out the local NIC, so the above re. routers doesn't apply in this situation.
In short there's no reason at all to expect that the above is anything other than acceptable.
如果您说您直接在实际生成数据包的计算机的 NIC 上进行测量（即这样可以消除所有网络影响），那么可能的原因是计算机本身的负载。
如果计算机上运行许多应用程序，尤其是交互式应用程序和具有强烈用户交互偏差的应用程序（这些应用程序往往会从大多数调度程序中获得优先级），那么您可能会发现创建消息的应用程序很难竞争它需要的时间。
即使您的所有客户计算机都加载了相同的软件，它们实际运行的应用程序以及它们正在执行的操作也可能会产生影响。
If you are saying that you are measuring this directly on the NIC of the computer actually generating the packets (i.e. so can discount all network influences) then a possible cause is the load on the computer itself.
If there are many applications running on the computer, especially interactive ones and ones with a strong user interaction bias (which tend to get priority from most schedulers), then you may find that your application creating the messages is simply finding it hard to compete for the time it needs.
Even if all your customer computers have the same software loaded, what applications they are actually running and what they are doing with them may have an influence.
伙计们，问题实际上是 Windows 的计时功能，事实上，Sleep() 的分辨率可能超过 15 毫秒。除非您以编程方式将其设置为 1 毫秒。所以与网卡没有任何关系。
Guys the problem was actually the timing functions of windows indeed it turn out that Sleep() may have resolution of more than 15 ms. unless you are programtically set it to one 1ms. So no relation what' so ever to NIC.