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

发布于 2024-09-26 07:13:10 字数 803 浏览 11 评论 0 原文

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

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

当然,如果没有 DAG 卡(它将对数据包进行硬件时间戳),我就不能依赖低于毫秒的维度精度。尽管如此,我正在寻找一个原因,为什么以下累积分布函数中存在这种差距:CDF for flow inter-arrival times

我还绘制了特定 IAT 看到的流量数量: alt text

我的数据基础包含 >13 Mio流动,所以这个差距不太可能是偶然存在的——我只是在寻找原因。

有……吗?与日程安排有关吗? 我知道 Linux 内核调度程序(是一台 debian 机器)使用 250Hz 的频率,因此每个时钟周期为 4ms,这比我的 35-170μsec 的差距大了 200 倍。 网卡有什么调度功能吗?看到许多 IAT 为 0 微秒,因此我假设这些数据包是直接在彼此之后处理的。我可以想象,我正在寻找的调度程序滴答声大约为 40μsec,导致 IAT 为 0120μsec 。

你知道我该如何解释这个差距吗? 多谢! 史蒂芬

I am doing research about network traffic characterization.
While processing collected data (captured by tcpdump and saved to a database), I stumbled over the weird phenomenon with packet (or flow) inter-arrival times:

Inter-arrival times of 35-170µsec are never observed

Of course, without a DAG card (which would do hardware time stamping of the packets), I can't rely on a precision in dimensions below msec. Nevertheless I'm searching for a reason, why this gaps exists in the following cumulative distribution function:CDF for flow inter-arrival times

I've also plotted the number of flows seen with a specific IAT: alt text

My data basis contains >13 Mio flows, so it's very unlikely that this gap exists by accident - I'm only searching for the reason.

Has it sth. to do with scheduling?
I know the linux kernel scheduler (was a debian machine) uses a frequency of 250Hz, thus each tick is 4ms, which is bigger than my gap of 35-170µsec by factor >200.
Is there any kind of scheduling done by the network card? There are many IATs of 0µsec seen, so I assume these packets are processed directly after each other. I can imagine that the kind of scheduler tick I'm searching for is about 40µsec, resulting in IATs of 0<x<40µsec and afterwards other things than my capturing is done (for 120µsec = 3ticks) and I get only ticks >120µsec.

Do you have a clue, how I could explain this gap?
Thanks a lot!
Steffen

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

伴梦长久 2024-10-03 07:13:10

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

到达间隔时间<35us的分组将对应于在一个中断中接收到的多个分组(具有不同的处理时间,取决于大小和协议)。 35us 本身相当于一次中断中可以接收的最大数据包数量(由于 NIC 缓冲区的大小),以及最坏情况下的处理时间。

This is just a hypothesis (aka WAG), but perhaps 170us is the minimum time between consecutive interrupts from the NIC (either due to the NIC hardware, the DMA controller, the interrupt controller, the CPU or some combination of all these).

The packets with inter-arrival times of <35us would correspond to multiple packets received in the one interrupt (with different processing times, depending on size and protocol). 35us itself would correspond to the maximum number of packets that can be received in one interrupt (due to the size of the NIC buffers), with the worst-case processing times.

伪装你 2024-10-03 07:13:10

真的不确定,但我可以想象该卡本身以一定的滴答率进行某种簿记。另外,35-170 µs 范围与数据包长度有何关系?

Not sure really, but I could imagine the card doing some kind of book-keeping itself with a certain tick rate. Also, how does the range 35-170 µs relate to a packet length?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文