时间戳

首页 > 解决方案 > Linux 上传入网络包的延迟 - 如何分析？

udp - Linux 上传入网络包的延迟 - 如何分析？

问题描述

问题是：有时 tcpdump 发现 UDP 数据包的接收被推迟到下一个传入的 UDP 数据包之前，尽管网络分流设备显示它通过电缆没有延迟。

场景：我在 Linux 上的 profinet 堆栈（位于用户空间）有一个循环连接，它每 4 毫秒（通过原始套接字）接收和发送 Profinet 协议数据包。根据该协议，大约每 30 毫秒它还会在 UDP 套接字上的另一个线程中接收 UDP 数据包并立即回复它们。大约 10% 的 CPU 负载。有时，接收到的 UDP 数据包似乎卡在网络驱动程序中。2 秒后，下一个 UDP 数据包进来，丢失的 UDP 数据包和下一个都被接收。没有丢弃的数据包。

我的测量：

  1. 我使用tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap将 UDP 流量记录到 RAM 磁盘文件。
  2. 同时我使用网络分流设备记录流量。

问题：

  1. 如何找出延迟的来源（或者是已知的影响）？（2. 时间戳（tcpdump 为每个数据包设置的）告诉我什么？我的意思是，它指的是哪个 OSI 层，换句话说：它是什么时候使用的？）

拓扑：“带有 Linux 和 eth0 的嵌入式设备”<---> tap-device <---> PLC。程序“tcpdump”正在嵌入式设备上运行。Tap 设备正在收听电缆。实际的 Profinet 连接是在 PLC 和嵌入式设备之间。一台 PC 连接在 Tap 设备上以记录它正在收听的内容。

Wireshark（通过 tap 和 tcpdump）：参见此处（tcpdump.pcap 中的数据包编号 3189）

标签： udplinux-device-drivertcpdump

解决方案

这是飞思卡尔快速以太网驱动程序 (fec_main.c) 中的一个错误，NXP 现在通过其强大的支持修复了该驱动程序。

实际答案（对于“如何找出延迟来自何处？”的问题）是：必须构建一个带有内核跟踪的 Linux，使用内核跟踪修补驱动程序代码，然后使用开发人员 Linux 工具分析这种跟踪跟踪命令。这是一件非常复杂的事情，但我很高兴它现在已修复：

trace-cmd record -o /tmp/trace.dat -p function -l fec_enet_interrupt -l fec_enet_rx_napi -e 'fec:fec_rx_tp' tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap

推荐阅读