libpcap 到达间隔时间和调度程序答案

【问题标题】：libpcap inter-arrival times and schedulerlibpcap 到达间隔时间和调度程序
【发布时间】：2011-04-21 19:04:34
【问题描述】：

我正在研究网络流量特征。在处理收集的数据（由 tcpdump 捕获并保存到数据库中）时，我偶然发现了数据包（或流）到达间隔时间的奇怪现象：

从未观察到 35-170 微秒的到达间隔时间

当然，如果没有 DAG 卡（它会对数据包进行硬件时间戳），我不能依赖低于毫秒的尺寸精度。尽管如此，我正在寻找一个原因，为什么在以下累积分布函数中存在这种差距：

我还绘制了使用特定 IAT 看到的流数：

我的数据库包含 >13 个 Mio 流，因此这种差距不太可能是偶然存在的 - 我只是在寻找原因。

有吗。与日程安排有关吗？ 我知道 linux 内核调度程序（是一个 debian 机器）使用 250Hz 的频率，因此每个滴答声是 4ms，这比我的 35-170µsec 的间隔要大 > 200。网卡是否有任何调度？有很多个 0µsec 的 IAT，所以我假设这些数据包是在彼此之后直接处理的。我可以想象我正在搜索的调度程序滴答时间约为 40 微秒，导致 IAT 为 0 120 微秒的滴答声。

你有什么线索，我该如何解释这个差距？非常感谢！史蒂芬

【问题讨论】：

标签： linux networking pcap libpcap tcpdump

【解决方案1】：

真的不确定，但我可以想象卡片会以一定的滴答率进行某种记账。此外，35-170 µs 范围与数据包长度有何关系？

【讨论】：

我的一个同事刚刚有一个理论，它可能是……。比如 120µsec 填充缓冲区和 40µsec 读取缓冲区.. 我看不出数据包大小和 IAT 之间的关系：1-3µsec 也发生在 1500bytes 数据包中，>200µsec 也发生在小数据包中。
有趣，他有这方面的任何数据，还是他只是像我一样胡编乱造？ :-)
不，我也只给他看图形。当然，最好有证明这种行为的原因，但有一些合理的假设也足够了，可能导致这种行为。

【解决方案2】：

这只是一个假设（又名 WAG），但也许 170us 是来自 NIC 的连续中断之间的最短时间（由于 NIC 硬件、DMA 控制器、中断控制器、CPU 或所有这些的某种组合)。

到达间隔时间

【讨论】：

谢谢，我搜索了 PCI 中断频率，我发现一件事是关于 Intel PRO/1000 XT：“~168 µs 的大截距表明驱动程序启用了中断合并，这是吞吐量测试证实，大约每发送 33 个（约 400 µs）数据包发生一次中断，每收到 10 个数据包（约 120 µs）发生一次中断。” datatag.web.cern.ch/datatag/pfldnet2003/papers/hughes-jones.pdf.
.. 而且我还使用了英特尔 PRO/1000 任何卡 - 所以一些中断处理听起来像是解释这种行为的一个很好的借口。