lwiperf压力测试跑不满100秒的现象正常吗

cdmar79

lwiperf.c用lwiperf_start_tcp_server_default跑压力测试，jperf显示带宽跑到了100M 的 80M~85M左右，感觉还行

但是有个问题，10秒的测试，基本能跑完；但是，100秒就经常中途断开（没有奔溃，新链接还是可以发起的），一般30秒到50秒，请教这会是什么原因？

eric2013

这种情况下，可能你的驱动实现还有点问题。

可以使用此贴的小软件测试下百万ping包，看看有问题没，可以锁定驱动问题。

ThreadX NetX的百万连续ping包测试通过，无丢包，耗时4小时25分钟
https://www.armbbs.cn/forum.php?mod=viewthread&tid=99151

cdmar79

eric2013 发表于 2025-3-31 09:19
这种情况下，可能你的驱动实现还有点问题。

可以使用此贴的小软件测试下百万ping包，看看有问题没，可以 ...

硬哥，我按你帖子，同样配置“忽略”和“永远”
ping了一个小时，没丢包
但是，lwiperf.c的测试还是一样，时间长不了
我这里的  流程是
1. irq触发（信号量）使 msg线程进行 接收dma数据读和搬到lwip栈内
2. 用os的timer，按sys_timeouts_sleeptime()，触发信号量使msg线程进行sys_check_timeouts
另，提供一个现象，跑你的ping，mcu使用率为1%,说明压力不大；用lwiperf.c，mcu使用率直接拉满到100%。我在想，会不会是因为接收100%，导致sys_check_timeouts没执行，最终导致端点认为 tcp 超时，从而停止

cdmar79

用 wireshark看了，只能

eric2013

cdmar79 发表于 2025-3-31 16:20
硬哥，我按你帖子，同样配置“忽略”和“永远”
ping了一个小时，没丢包
但是，lwiperf.c的测试还是一 ...

这样的话，移植可能没问题。那主要看应用代码和iperf测试了

cdmar79

不好搞哦，怎么感觉是  本机的 网卡丢包了
硬哥给看下

cdmar79

排查出来原因了，接收到了 错误报文，如图两种情况，有多有少
请问，这个会和什么有关，是硬件问题（线路干扰了）？

cdmar79

终于跑到100秒了，排查的几点总结：
1. 中断要开启  接收上溢，用于排查是否发生了  这个错误异常，这个异常可能导致  校验错误/phy接收缓存冲毁 等一系列问题，导致丢帧，然后 tcp就认为丢包了
2. 在发现接收上溢的情况后，我增加了接收描述符的配置数量（具体增加多少，可以按是否发生   接收上溢  为依据进行调整；发生就再加点、除非内存不够）
3. 完成以上处理后，我终于跑出了如图的100秒测试，但100秒内仍然发生了8~10次头校验和错误，具体原因不明，下面是手册的解释

IPv4/IPv6类型帧，检测到报头校验和错误。
该错误可能原因：
1) 类型域值与数据包中的版本值不一致
2) 计算的报头校验和值与报头校验和域值不匹配
3）IP报头字节数不足
出错帧的示例数据：
001EC0394D50E4A8DFD1B08A0800450005DCB1B4400040060000C0A8010BC0A8010CE9EC13896E8A4177000019985010FAF08501000030313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738398E14E3B90000E3B9

由于wireshark上的tcp报文大小与此帧的大小不一致，应该是发送方出来的ip分包的原因，所以，很难查出此帧到底是什么原因导致会头校验和错误

但此时，已经不会发生卡死中断测试的情况


鉴于以上测试现象，后续还是继续改进以下问题：
1. irq->recv的性能问题，recv在irq发生后越早处理，越不容易发生上溢；但recv又不能直接放在irq内？（又或许可以放在irq内，要再想想）。    这里请硬哥给点指导，我看你说开源freeos的lwip项目，好像也没开出来吧

cdmar79

硬哥，还是问题找你了
发生四次超时，其中的错误码是 rx描述符的status
0x004E83A0   分析后，错误仍然是



IPv4/IPv6类型帧，检测到报头校验和错误。
该错误可能原因：
1) 类型域值与数据包中的版本值不一致
2) 计算的报头校验和值与报头校验和域值不匹配
3）IP报头字节数不足


这个问题依旧，但现在我是在中间加了路由器的，那至少路由器转板端前是对的，否则，路由器就不会转吧
如果是这样，会不会就是板子有问题，被干扰了？

eric2013

cdmar79 发表于 2025-4-3 14:41
硬哥，还是问题找你了
发生四次超时，其中的错误码是 rx描述符的status
0x004E83A0   分析后，错误仍然是 ...

有个地方我觉得你可以测试下，将RMII所涉及到GPIO的速度等级先配置到最低的low开始测试，然后逐步提升等级

cdmar79

问题已解决
驱动层的  MAC_CFG.IPFCO （ IP帧数据校验和）改为0，禁止接收端TCP/UDP/ICMP报头的校验和检验功能，就正常了
感觉应该是对端ip分包后，如果开启，会进行硬校验，结果会放在rx描述符中，导致程序判断认为是错误帧：因为ip分包后，第二帧本身就是缺TCP/UDP/ICMP的长度和校验项的