[参考译文] AM623：公司网络环境中 AM62x 上的网络通信超时

尊敬的专家：

您愿意分享一些建议吗？

谢谢。

Daniel

您好 Daniel、

在回复的延迟中道歉

在高流量企业网络中运行时、CPSW3G（3 端口千兆交换机）是否存在已知问题或建议的配置？

在高流量网络中、通常使用各种技术来防止 DDoS 攻击等问题、其中最常见的是限制传入流量的速率。  有一些建议可以通过软件使用从这个演示文稿,我们最近做了去年: https://osseu2025.sched.com/event/25Vwj?iframe=no 请看看,看看这些方法是否可以帮助解决你看到的问题.  

由于测试 C 位于高流量网络环境中、因此在发生这些超时时时检查 CPU 负载/使用情况也是不错的选择。 我猜由于高流量网络向 TI 器件发送了大量帧、CPU 负载非常高。 如果是这种情况、则对该流量采用速率限制将很有用。 该演示概述的另一种建议是使用 eBPF 滤波器仅筛选 TI 器件上所需的流量、并丢弃所有其他流量。

您使用的是哪个 SDK 版本？

这是在 TI AM62x EVM 还是在定制电路板上进行测试？

您能否分享准确的超时日志消息？

-道林

嗨、Daolin

感谢您的答复。

SDK  版本：11.01.05.03   发布日期：2025 年 7 月 15 日

TI AM6234 是定制电路板。

我们无法附加完整日志、这里是您的部分日志

===============Test_info===============
Socket Type: TCP
Local IP:192.168.0.193
Local Port:51552
Peer IP:192.168.0.198
Peer Port:500
============================================

our SW detect an error and reopen the connection

W@41:39.388	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.423	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.460	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.494	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.531	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.566	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.603	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.638	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.674	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.709	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.746	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.781	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.818	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.853	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.889	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:39.923	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:39.961	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:40.068	[0]<>	0x400a0000(13)

S@41:40.081	6
S@41:40.093	0
S@41:41.151	1
S@41:41.164	2
S@41:41.176	3
W@41:41.192	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.226	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.268	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.303	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.350	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.385	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.423	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.458	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.495	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.530	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.567	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.601	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.640	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.674	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

W@41:41.713	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@41:41.748	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)


the connection states

S@41:40.081 6
S@41:40.093 0
S@41:41.151 1
S@41:41.164 2
S@41:41.176 3

mapping to 

enum SocketState {
  UnconnectedState,
  HostLookupState,
  ConnectingState,
  ConnectedState,
  BoundState,
  ListeningState,
  ClosingState
};

我们以前的 DUT (am3352) 没有超时、也通过了测试。 我们是否应该检查 am6234 上的任何设置？

此致、

Scott

嗨、Daolin

超时时不确定外部 CPU 负载、但运行测试时 CPU 负载保持在 3~5%。

Mem: 690772K used, 257900K free, 344K shrd, 31716K buff, 422812K cached
CPU:   0% usr   0% sys   0% nic  90% idle   7% io   0% irq   0% sirq
Load average: 0.52 0.34 0.33 2/138 919
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
  497   468 root     S     307m  33%   2% /application/firmware
  580     2 root     SW       0   0%   0% [usb-storage]
  488   224 root     S    18960   2%   0% /sbin/udevd -d
  918   903 root     R     3064   0%   0% top
  916     2 root     IW       0   0%   0% [kworker/u16:1-e]
  917     2 root     IW       0   0%   0% [kworker/u16:3-e]
  191     1 root     S    65344   7%   0% /application/wdt
  557     1 root     S    34180   4%   0% /application/vncserver -t /dev/input/event0
  475   224 root     S    18960   2%   0% /sbin/udevd -d
  487   224 root     S    18960   2%   0% /sbin/udevd -d
  489   224 root     S    18960   2%   0% /sbin/udevd -d
  224     1 root     S    18888   2%   0% /sbin/udevd -d

此致、

Scott

我们今天捕获的另一个包含 CPU 负载的日志

[CPU] 11 %
W@39:58.283	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.288	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 6 %
W@39:58.324	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.329	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@39:58.365	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.370	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@39:58.407	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.411	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 17 %
W@39:58.448	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.453	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 10 %
W@39:58.499	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.505	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 7 %
W@39:58.540	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.545	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 6 %
W@39:58.581	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.586	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 13 %
W@39:58.623	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:58.627	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 3 %
W@39:58.664	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@39:59.202	[0]<>	0x400a0000(13)

[CPU] 25 %
S@39:59.224	6
[CPU] 57 %
S@39:59.238	0
[CPU] 3 %
S@40:00.207	1
[CPU] 40 %
S@40:00.222	2
[CPU] 20 %
S@40:00.236	3
[CPU] 25 %
W@40:00.258	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.264	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 25 %
W@40:00.300	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.306	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 10 %
W@40:00.352	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.358	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 6 %
W@40:00.403	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.408	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@40:00.444	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.449	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@40:00.486	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.491	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@40:00.527	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.532	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 13 %
W@40:00.568	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.572	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 13 %
W@40:00.609	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.614	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 12 %
W@40:00.649	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.655	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

[CPU] 16 %
W@40:00.692	[16]02 30 31 34 36 30 31 44 30 31 30 33 30 36 36 03 <014601D0103066>
R@40:00.703	[13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD>	0x00000000(13)

此致、

Scott

嗨、 Daolin

可以帮助解决这个问题吗？

谢谢

Daniel

尊敬的 Daniel：  

对延迟的回复表示歉意。  

我们无法附加完整日志、下面是您的部分日志

感谢您附加日志、但我不完全了解日志应该指出/显示的内容？ 您能帮我理解吗？ 我希望在您描述的超时发生时内核是否显示任何超时错误消息。  

CPU 加载在运行测试时保持在 3~5%。

好的、如果是这种情况、则可能不是 CPU 过载导致超时问题。

另一个检查数据包丢失的选项是使用“ip -s link show dev “。 这应该显示高于使用“ethtool -S“可以观察到的一层的统计数据。

您在设置中看到的总吞吐量是多少？  

-道林

嗨、 Daolin

我来为您解释一下日志

==================================================

[CPU] 13%
W@39：58.623 [16]02 30 31 34 36 30 31 44 30 31 30 33 36 36 03 <014601D0103066>
R θ@39：58.627 [13]02 30 31 34 36 30 30 30 30 30 42 44 03 <014600000BD> 0x00000000 (13)

[CPU] 值表示 CPU 加载来自顶部命令

[W]表示写入数据包发送

[R]表示接收到读取数据包

[39：58.623]是时间

[02 30 31 34 36 30 31 44 30 31 30 33 30 36 03 ] 这是很小的数据包有效载荷

如您所见、1 秒内可能会有 10~15 μ s 写入数据包发送和 10~15 μ s 读回数据包。

0x400a0000 (13) 表示超时

 SW 视图中的连接状态、SW 已重试

S@41：40.081 6 => ClosingState
S@41：40.093 0 => UnconnectedState
S@41：41.151 1 => HostLookupState
S@41：41.164 2 => ConnectingState
S@41：41.176 3 => ConnectedState

===================================================

我们开始另一个测试 、并捕获“ip -s link show dev “ 。

此致、

Scott

嗨、 Daolin

此处连接的日志从无数据包丢失开始到总共 发生 6 个超时。

e2e.ti.com/.../am6234_5F00_network_5F00_test.log

此致

Scott

嗨、 Daolin

我们应用了 您的视频中的 tc 速率限制方法大约 2 小时、直到现在、我们有 50 个超时（大约 19 小时测试）

此致、

Scott

您好、Scott：  

感谢您尝试 tc  速率限制方法、但演示中提到的方法侧重于解决传入流量高导致的 CPU 负载过重的问题。 由于日志显示 CPU 负载较低、速率限制技术可能不是很适用。  

在高流量网络中、通常使用各种技术来防止 DDoS 攻击等问题、其中最常见的是限制传入流量的速率。  有一些建议可以通过软件使用从这个演示文稿,我们最近做了去年: https://osseu2025.sched.com/event/25Vwj?iframe=no 请看看,看看这些方法是否可以帮助解决你看到的问题.  [/报价]

您的日志报告的超时似乎来自应用程序代码？ 您能描述一下您的应用程序代码如何检测超时问题吗？ 由于 dmesg 日志中的内核、我没有看到任何超时错误。 我确实看到 ip -s 链路 show eth0 报告了大量 RX 丢弃的数据包、但 ethtool -S eth0 没有显示任何 rx_crc_errors。 但是、我无法确定这是否是导致超时问题的原因、因为我不确定您的设置/应用程序代码中的超时是否是由于检测到丢弃了大量 RX 数据包而导致的。

-道林

嗨、Daolin

这是我们 SW 的参考代码

 

此致、

Scott

您好、Scott：  

根据您的代码、超时似乎由您的应用代码定义、可能是由于网络层较高的问题、不一定是更低级别的硬件或 CPSW 以太网驱动程序问题导致的。  这似乎源于比较您的“ethtool -S“和“ip -s link show“日志、其中从“ethtool -S“中未观察到 RX 错误、但“ip -s link show“似乎显示了丢弃的 RX 数据包。  我们通常仅支持与较低级别的硬件或 CPSW 以太网驱动程序问题直接相关的问题、通常不支持应用或系统级问题、但我有以下建议。

根据您的代码、您似乎正在使用 TCP 套接字、并在递增“timeout_count"之前“之前检查从 TCP 套接字接收的字节是否小于“expect_rsp_len"。“。 “ip -s link show“指示的丢弃数据包可能会导致此问题。

您能否使用 iperf3 实用程序工具测试 TCP 流量、看看“ip -s link show“统计信息是否也显示丢弃了 RX 数据包？

您是否还能检查“cat /proc/net/snmp “的结果、它可以很好地了解堆栈中的 TCP/UDP 是否丢弃了数据包。 如果这显示 TCP 下降、则最好检查 TCP 套接字缓冲区大小是否可以增加。

RX 数据包被丢弃的原因可能有多种。 由于日志报告的 CPU 负载较低、因此我们可以排除#5。 #4 会在您的“ip -s link show“结果中显示“超支“。 #3 仅当您已设置这些过滤器时才应出现。 #1 和#2 仍然可能是您可能要研究的可能性。

1. 缓冲区/环溢出:网络接口接收数据包的速度比内核处理数据包的速度快

2. 资源限制：系统内存不足、无法为传入的数据包分配内存

3. 共模滤波:数据包被防火墙规则、BPF 过滤器或其他过滤机制有意丢弃

4. 队列溢出：特定 RX 队列在硬件仍正常工作时达到容量

5. CPU 饱和：系统无法分配足够的 CPU 时间来处理传入的数据包

-道林

嗨、Daolin

#1 和#2 仍然可能是您可能要研究的可能性。

对于#1、 我们尝试进行设置 缓冲区/振铃  通过 ethtool -g  eth0 和 ethtool -G eth0 Rx 4096 TX 4096  但失败了

我们还尝试 从 drivers\net\Ethernet\ti\am65-cpsw-nuss.c 修改 AM65_CPSW_MAX_RX_DESC  

/*每个通道/流的 TX/RX 描述符数量*/
#define AM65_CPSW_MAX_TX_DESC 500
#define AM65_CPSW_MAX_RX_DESC 500 --> 1000 执行 1000 甚至更大的操作是正确的吗？

再次运行相同的测试、但仍然会发生超时

--------------------------------------------------------------------

对于#2、 通过 free -h cmd 检查是否正确、它显示了？  

# free -h
     总计          自由使用     共享  缓冲/高速缓存  可用
内存：926.4M  161.1M  632.9M  316.0K 132.4M       699.2M
交换：    0        0        0
#

----------------------------------------------------------------

#4 会在您的“ip -s link show“结果中显示“超支“。

哪一个 在  “ip -s link show“结果中超支？

3：eth0： MTU 1500 qdisc mq 状态 up 模式默认组默认值 qlen 1000
链路/醚 9e：19：6e：58：6F：1e brd ff：ff：ff：ff：ff：ff：ff：ff：ff
RX：字节数据包错误丢弃了未命中的 mcast
4828578441 3207767 0 1266 0
TX：字节数据包错误丢弃运营商拼贴
85924736 1591160 0 0 0 0

----------------------------------------------------------------

不过

以下是随附的 iperf3 测试日志 、其中包含 ip -s link show；ifconfig eth0；cat /proc/net/snmp；

e2e.ti.com/.../iperf3.log

----------------------------------------------------------------

根据 AM3352 (10y ago) 和其他 竞争对手的 平台、同样的通信测试没有超时。

希望在这里找到案例。

----------------------------------------------------------------

此致、

Scott

您好、Scott：

[引述 userid=“435952" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1623640/am623-network-communication-timeout-on-am62x-in-corporate-network-environment/6282472

#4 会在您的“ip -s link show“结果中显示“超支“。

哪一个 在  “ip -s link show“结果中超支？

[/报价]

抱歉、我得到了“ip -s link show“和“ifconfig"混合“混合信息。 我认为“ifconfig"应“应显示有关“超支“的信息。

从 ifconfig 日志中、我没有看到“overruns"增量“增量、因此我认为#4 不是问题所在。

不过、我仍然看到、即使在运行 iperf3 TCP 流量时、“ip -s link show“和“ifconfig"日志“日志中的 RX 路径也出现下降。  

由于使用的是 TCP、因此不会因 TCP 流量而导致任何下降、因为它只会重新传输流量。 运行 TCP iperf3 测试时是否看到多次“重试“？  

我的下一个建议是研究 CPSW 以太网驱动程序代码 (am65-cpsw-nuss.c)、以查看从“ip -s link show“中看到的 RX 中断的原因。  https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/am65-cpsw-nuss.c?h=ti-linux-6.12.y-cicd#n1732 中 显示的一个区域用于描述符页池分配（可能是添加调试打印语句）。 可能还有其他导致“ ndev->stats.rx_dropped++;" to look into in the code to see what conditions might be causing this behavior.

此外、“sysctl net.ipv4.tcp_rmem“、“sysctl net.ipv4.tcp_wmem“、“sysctl net.core.netdev_max_backlog“?的结果是什么

-道林

嗨、Daolin

抱歉、我得到了“ip -s link show“和“ifconfig"混合“混合信息。 我认为“ifconfig"应“应显示有关“超支“的信息。

=>这是好的,只是仔细检查是否有任何我们可能错过 

由于使用的是 TCP、因此不会因 TCP 流量而导致任何下降、因为它只会重新传输流量。 运行 TCP iperf3 测试时是否看到多次“重试“？

=>否、我没有看到任何重试、这是完整日志。

在代码中进行研究、以了解导致此行为的条件

=>如果您需要、我可以帮助添加调试代码。  

结果是什么

=> # sysctl net.ipv4.tcp_rmem
=>  net.IPv4.tcp_rmem = 4096 131072 6291456
=> # sysctl net.ipv4.tcp_wmem
=>  net.ipv4.tcp_wmem = 4096 16384 4194304
=> # SYSCTL net.core.netdev_max_backlog
=>  net.core.netdev_max_backlog = 1000

ssh 登录后、系统 变得非常卡滞、

当 CPU 负载较低时 => CPU：  2% USR  2% sys  0% NIC 94%空闲  0% IO 0%  IRQ 0%  sirq

内存=> 639.8M 空闲（总计 926.4M）

此致、

Scott

您好、Scott：

[引述 userid=“435952" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1623640/am623-network-communication-timeout-on-am62x-in-corporate-network-environment/6284340

在代码中进行研究、以了解导致此行为的条件

=>如果您需要、我可以帮助添加调试代码。  

[/报价]

我认为在显示“ndev->stats.rx_drop++;"的“的位置向驱动程序代码中添加 print 语句、重建内核映像和模块、然后在设备上重新运行 TCP iperf3 测试、检查是否出现 RX 中断、如果内核日志显示 print 语句出现、将有助于确定导致中断的条件。  

此时、我不确定“ip -s link show“的 RX 是否会直接导致您的超时问题、但这无疑是一个需要考虑的问题。 如果我们可以找出原因、请进行修复、然后检查超时问题是否仍然存在、然后我们可以确定压降是否导致了超时问题。

[报价 userid=“435952" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1623640/am623-network-communication-timeout-on-am62x-in-corporate-network-environment/6265979 ]SDK  版本：11.01.05.03   发布日期：2025 年 7 月 15 日

我知道这并不总是很容易、但您是否可以使用最新的 SDK 进行测试？ （应是 SDK 11.02）

为了仔细检查、您的应用程序代码专门关注的是 TCP 流量？

-道林

嗨、Daolin

我认为 跌落 pkt 不是来自 iperf 它是由于环境?

我会首先添加一些 dbg、 如果需要、SDK 11.02 将是一项巨大的工作。

应用程序代码具体关注的是 TCP 流量？  =>是

此致、

Scott

您好、Scott：

我认为 跌落点 pkt 不是来自 iperf 它是由于环境造成的？

从“ip -s link show“中显示的 DROP pkts 在 iperf 检测之前进行、通常与 Linux 网络堆栈/内核相关、在将数据包传递到 iperf 套接字之前可能没有足够的缓冲区空间来保存数据包、但我不确定是否要直至根据调试打印语句确定特定条件。

-道林