0

我无法解决 Windows 上的 recvfrom 功能问题。
请参阅我编写的代码的以下部分。我在 Linux 和 Windows 上运行此代码，并在 udp 比特率值中得到不同的结果。

在 Windows 上使用 Cygwin 编译它时，我得到与在 Ubuntu 上相同的结果，没关系。我将此与参考工具进行了比较。

当使用 MinGW 在 Windows 上编译它时，我得到更小的 upd 比特率值，这是由于一秒内的 while(1) 循环迭代次数较少（计数器变量）以及相关的 - 在 1 秒内捕获的数据量较少（data_in_1_sec多变的）。在 Windows 上使用 MinGW 的 recvfrom 功能似乎最慢，并且会跳过 udp 数据。
请注意，如果使用 MinGW，两个操作系统上的 upd 比特率大约为 0.200 Mbps，结果是相同的。在 UDP 比特率约为 20 Mbps 的数据上可以看到问题。

不幸的是，我不得不使用 MinGW，因为该代码作为静态库加载到 Python 代码中。使用 CygWin dll 我在 Python 下运行此函数时遇到访问冲突。

如何处理？

我使用的是 Windows 7 Professional 64。

我使用的代码：

while (1) {
    #ifdef _WIN32
        // start timer
        QueryPerformanceCounter(&t1);           
    #elif __linux
        clock_gettime(CLOCK_MONOTONIC, &start);
    #endif

   udp_packet_len = recvfrom(sock, udp_packet, buff_len, 0, (struct sockaddr *) &addr, &addrlen);
    #if DEBUG == 1
        counter++;
    #endif

    #ifdef _WIN32
       // stop timer
       QueryPerformanceCounter(&t2);        
    #elif __linux
       clock_gettime(CLOCK_MONOTONIC, &finish);
    #endif

   data_in_1_sec += (double)udp_packet_len;

    #ifdef _WIN32
       temp = (t2.QuadPart - t1.QuadPart);
       temp *= 1000000000.0;    
       temp /= frequency.QuadPart;
       temp /= 1000000000.0;
       second += temp;
    #elif __linux
       temp = (finish.tv_sec - start.tv_sec);
       temp += (finish.tv_nsec - start.tv_nsec) / 1000000000.0;
       second += temp;
    #endif

   if(second >=1.0) {
       processing.udp_bitrate = (((data_in_1_sec) * 8.0) /second);

        #if DEBUG == 1
            fprintf(stderr,"\nudp_bitrate: %f\n",processing.udp_bitrate);
            fprintf(stderr,"data_in_1_sec: %f\n",data_in_1_sec);
            fprintf(stderr,"second: %f\n",second);
            fprintf(stderr,"counters: %d\n",counter);
            counter = 0;
        #endif

       data_in_1_sec = 0;
       second = 0.0;
   }

此代码的结果，
对于 Windows：

udp_bitrate: 19799823.828382
data_in_1_sec: 2505664.000000
second: 1.012399
counters: 1904

udp_bitrate: 19389475.566430
data_in_1_sec: 2451708.000000
second: 1.011562
counters: 1863

udp_bitrate: 18693904.033320
data_in_1_sec: 2367484.000000
second: 1.013158
counters: 1799

udp_bitrate: 18963187.258098
data_in_1_sec: 2399068.000000
second: 1.012095
counters: 1823

udp_bitrate: 19452989.621014
data_in_1_sec: 2459604.000000
second: 1.011507
counters: 1869

udp_bitrate: 19795284.196391
data_in_1_sec: 2509612.000000
second: 1.014226
counters: 1907

相同数据的 Ubuntu 输出 

udp_bitrate: 22016976.870087
data_in_1_sec: 2788604.000000
second: 1.013256
counters: 2119

udp_bitrate: 22022223.539749
data_in_1_sec: 2787288.000000
second: 1.012536
counters: 2118

udp_bitrate: 22003055.797884
data_in_1_sec: 2785972.000000
second: 1.012940
counters: 2117

udp_bitrate: 22041580.024322
data_in_1_sec: 2788604.000000
second: 1.012125
counters: 2119

udp_bitrate: 22025510.655441
data_in_1_sec: 2782024.000000
second: 1.010473
counters: 2114

udp_bitrate: 22412560.109513
data_in_1_sec: 2801764.000000
second: 1.000069
counters: 2129
4

1 回答 1

0

UDP 是一种不可靠的传输方式。丢弃数据包是一种允许的行为，并且在数据传输速率超过接收器处理数据的速率的情况下，这是可以预料的。

Cygwin 和 MinGW 是独立的项目。它们每个都提供自己的recvfrom()构建在 Windows 内核和 API 之上的包装器。可以想象，Cygwin 的实现效率更高一些，在您的测试条件下提供的带宽比 MinGW 的高 10%。

也可能是您的仪器干扰了您的测量。至少某些版本的 Cygwin 默认情况下不会由_WIN32预处理器定义，而 MinGW 会，因此您可能正在使用clock_gettime()Cygwin，而 Windows 性能计数器则与 MinGW 一起使用。您会认为 Windows 性能计数器的开销足够低，因此这种差异可以忽略不计，但您会对其进行大量调用。您应该考虑通过对固定次数的迭代运行测试并仅对所有这些迭代的总和计时（每次速率测量只有一个计时器启动/停止）来最小化这两个来源的开销。

底线：您的测试方法可以改进，但即使结果很好地反映了被测不同实现的行为，它们也不会揭示任何根本错误。

于 2016-09-06T15:03:48.487 回答