c - 如果我使用休眠模式，为什么测得的网络延迟会发生变化？

Question

我正在尝试确定机器接收数据包、处理数据包并返回答案所需的时间。

这台机器，我称之为“服务器”，运行一个非常简单的程序，它在缓冲区中接收数据包 (recv(2))，复制接收到的内容 ( memcpy(3)) 到另一个缓冲区并将数据包发回 (send(2))。服务器运行 NetBSD 5.1.2。

我的客户多次测量往返时间(pkt_count):

struct timespec start, end;
for(i = 0; i < pkt_count; ++i)
{
    printf("%d ", i+1);

    clock_gettime(CLOCK_MONOTONIC, &start);        
    send(sock, send_buf, pkt_size, 0);
    recv(sock, recv_buf, pkt_size, 0);
    clock_gettime(CLOCK_MONOTONIC, &end);        

    //struct timespec nsleep = {.tv_sec = 0, .tv_nsec = 100000};
    //nanosleep(&nsleep, NULL);

    printf("%.3f ", timespec_diff_usec(&end, &start));
}   

为了清楚起见，我删除了错误检查和其他次要内容。客户端在 Ubuntu 12.04 64 位上运行。这两个程序都以实时优先级运行，尽管只有 Ubuntu 内核是实时的 (-rt)。程序之间的连接是TCP。这工作正常，平均为 750 微秒。

但是，如果我启用注释掉的 nanosleep 调用( sleep 时间为 100 µs)，我的测量值会下降 100 µs，平均为 650 µs。如果我休眠 200 微秒，测量值会下降到 550 微秒，依此类推。这一直持续到 600 µs 的 sleep ，平均为 150 µs。然后，如果我将 sleep 时间提高到 700 微秒，我的测量值平均会上升到 800 微秒。我用 Wireshark 确认了我的程序的措施。

我不知道发生了什么。我已经在客户端和服务器中设置了 TCP_NODELAY 套接字选项，没有区别。我使用 UDP，没有区别(相同的行为)。所以我猜这种行为不是由于 Nagle 算法造成的。会是什么？

[更新]

这是客户端和 Wireshark 输出的屏幕截图。现在，我在另一台机器上运行我的服务器。我使用具有相同配置的相同操作系统(因为它是笔式驱动器中的 Live System)，但硬件不同。这种行为没有出现，一切都按预期进行。但问题仍然存在:为什么它会发生在以前的硬件中？

[更新 2:更多信息]

正如我之前所说，我在两台不同的服务器计算机上测试了我的程序对(客户端/服务器)。我绘制了获得的两个结果。

第一台服务器(奇怪的)是 RTD Single Board Computer , 具有 1Gbps 以太网接口(interface)。第二台服务器(普通服务器)是 Diamond Single Board Computer具有 100Mbps 以太网接口(interface)。它们都从相同的 pendrive 运行相同的操作系统 (NetBSD 5.1.2)。

从这些结果来看，我确实相信这种行为是由于驱动程序或 NIC 本身造成的，尽管我仍然无法想象为什么会发生...

Answer 1

好吧，我得出结论了。

我在服务器上使用 Linux 而不是 NetBSD 尝试了我的程序。它按预期运行，也就是说，无论我 [nano] 在代码的那一点睡了多少，结果都是一样的。

这个事实告诉我，问题可能出在NetBSD 的接口(interface)驱动程序上。为了识别驱动程序，我读取了 dmesg 输出。这是相关部分:

wm0 at pci0 dev 25 function 0: 82801I mobile (AMT) LAN Controller, rev. 3
wm0: interrupting at ioapic0 pin 20
wm0: PCI-Express bus
wm0: FLASH
wm0: Ethernet address [OMMITED]
ukphy0 at wm0 phy 2: Generic IEEE 802.3u media interface
ukphy0: OUI 0x000ac2, model 0x000b, rev. 1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto

因此，如您所见，我的界面名为 wm0。根据this (第 9 页)我应该通过查阅文件 sys/dev/pci/files.pci 第 625 行(here)来检查加载了哪个驱动程序。它显示:

# Intel i8254x Gigabit Ethernet
device  wm: ether, ifnet, arp, mii, mii_bitbang
attach  wm at pci
file    dev/pci/if_wm.c         wm

然后，通过搜索驱动程序源代码(dev/pci/if_wm.c, here)，我发现了一段可能会改变驱动程序行为的代码:

/*
 * For N interrupts/sec, set this value to:
 * 1000000000 / (N * 256).  Note that we set the
 * absolute and packet timer values to this value
 * divided by 4 to get "simple timer" behavior.
 */

sc->sc_itr = 1500;              /* 2604 ints/sec */
CSR_WRITE(sc, WMREG_ITR, sc->sc_itr);

然后我将这个 1500 值更改为 1(试图增加允许的每秒中断数)和 0(试图完全消除中断限制)，但这两个值产生了相同的结果:

• 没有 nanosleep:延迟大约 400 us
• 100 微秒的纳秒 sleep :延迟约为 230 微秒
• 200 微秒的纳秒 sleep :延迟约为 120 微秒
• 260 微秒的纳秒 sleep :延迟约为 70 微秒
• 270 微秒的纳秒 sleep :延迟约为 60 微秒(我能达到的最小延迟)
• 任何超过 300 微秒的纳米 sleep :~420 微秒

这至少比以前的情况表现得更好。

因此，我断定该行为是由于服务器的接口(interface)驱动程序引起的。我不愿意进一步调查它以找到其他罪魁祸首，因为我正在从 NetBSD 转移到 Linux 以进行涉及此单板计算机的项目。