【问题标题】:Inconsistent packet delivery by NIC, NIC performance measurementNIC 的数据包传递不一致,NIC 性能测量
【发布时间】:2011-01-07 20:54:30
【问题描述】:

我们的一位客户在使用我们的流媒体应用程序 (win32) 时遇到问题。似乎应该由应用程序以某个恒定间隔(例如 20 毫秒)发送的 UDP(RTP)数据包实际上以可变的增量(例如 15 毫秒 - 25 毫秒 - 10 毫秒 - 30 毫秒)发送。这是唯一遇到此问题的客户,因此网卡或其他与操作系统网络相关的基础设施是我们的主要嫌疑人。

问题是什么样的网络配置可能会引入这样的问题(AV?,QOS?)

我如何测量实际调用“发送”函数和数据包实际传送到网络之间的时间?有没有可用的工具。

【问题讨论】:

    标签: winapi network-programming udp qos


    【解决方案1】:

    我怀疑任何网络问题都可能导致此问题。

    基本 UDP 没有 QoS(服务质量)的概念(甚至可能会丢失数据包、重复数据等)。您的网卡必须将数据包排队以写入网络,因此您无法保证交付,因为它正在排队来自不同应用程序的数据包。

    路由器也可以设置优先级,这将影响这些数据包的规律性。

    编辑:你已经指出了本地网卡,所以上面的 re.路由器不适用于这种情况。

    简而言之,完全没有理由期望上述内容是可以接受的。

    【讨论】:

    • 这是唯一遇到此问题的客户。没有人谈论完美的时机,但与该客户发送数据包时间的可变性远远超出了通常观察到的范围
    • 请注意,我们所说的是捕获本地 NIC,因此不涉及路由器或网络问题。
    【解决方案2】:

    如果您说您是在实际生成数据包的计算机的 NIC 上直接测量此值(即可以忽略所有网络影响),那么可能的原因是计算机本身的负载。

    如果计算机上运行着许多应用程序,尤其是交互式应用程序和具有强烈用户交互偏差的应用程序(这往往会从大多数调度程序中获得优先权),那么您可能会发现创建消息的应用程序很难争取它需要的时间。

    即使您的所有客户计算机都加载了相同的软件,它们实际运行的应用程序以及它们正在做什么也可能会产生影响。

    【讨论】:

      【解决方案3】:

      伙计们,问题实际上是窗口的计时功能,事实上,Sleep() 的分辨率可能超过 15 毫秒。除非您以编程方式将其设置为 1 毫秒。所以与 NIC 没有任何关系。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-04-02
        • 1970-01-01
        • 1970-01-01
        • 2021-10-16
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多