gpt4 book ai didi

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

转载 作者:IT王子 更新时间:2023-10-29 00:01:48 25 4
gpt4 key购买 nike

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

这台机器,我称之为“服务器”,运行一个非常简单的程序,它在缓冲区中接收数据包 (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),但硬件不同。这种行为没有出现,一切都按预期进行。但问题仍然存在:为什么它会发生在以前的硬件中?

Output Comparison

[更新 2:更多信息]

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

Comparison between two servers

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

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

最佳答案

好吧,我得出结论了。

我在服务器上使用 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 以进行涉及此单板计算机的项目。

关于c - 如果我使用休眠模式,为什么测得的网络延迟会发生变化?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16043843/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com