项目

一般

简介

错误 #259

ping包时延过大

由 guo hanlin 在 超过 4 年 之前添加. 更新于 大约 4 年 之前.

状态:
已解决
优先级:
高
指派给:
guo hanlin
开始日期:
2020-10-27
计划完成日期:
% 完成:

90%

预期时间:
问题归属:

描述

Server到APP的ICMP包来回时延过大，从40ms到3s不等

历史记录

#1

由 guo hanlin 更新于 超过 4 年 之前

  • 状态 从 新建 变更为 进行中
  • 优先级 从 普通 变更为 高

Wireshark抓到两条重复的ICMP request, 第二条request与reply的间隔之间只有几us,网上查找发现：

Wireshark is very likely trying to tell you that it has a bug, probably Bug 11414 __

Retrieved from
https://ask.wireshark.org/question/1990/meaning-of-several-no-response-found-but-ping-from-pc-working/

#2

由 guo hanlin 更新于 超过 4 年 之前

初步定位到时延大的部分为testmac_udp_tx部分，继续分析发现是由于前一个包的发送条件是下一个包已将被放置到buffer里，但由于下一个包的到达时间不确定，即下一个包与前一个包的时间间隔是不定的，所以造成时延过大且每次时延都不同；

测试中临时修改机制，第一个包放置到buffer后，只要pop_data_from_rb 存在ask的需求，就将这个包发出，测试结果为testmac_udp_tx部分时延从最大1s缩短为400us内

#3

由 guo hanlin 更新于 超过 4 年 之前

内环测试：ping时延大概为3ms

#4

由 guo hanlin 更新于 超过 4 年 之前

  • 状态 从 进行中 变更为 转测试
  • % 完成 从 0 变更为 90
#5

由 guo hanlin 更新于 大约 4 年 之前

  • 状态 从 转测试 变更为 已解决

修改了testmac_udp发端的机制，即不需要等待将ring buffer中的一个TB填满再发送至物理层，每个slot都会读取ring buffer中一个节点的TB大小数据，保证小包也能及时被发送出去。若设置MTU为1514，由于UDP包的发包间隔时间约为20us，在灌包带宽达到500M时可能造成丢包，因此在带宽500Mbps以上的时候尽量将包大小设置的大一些（3000+），利用网卡的机制将大包分割，可以最大提高灌包速率达到峰值。

另：当前测试是在射频直连的情况下进行的，频点不易设置太高，在小于等于3.0GHz的情况下可以保证CRC错误低于2%

导出 Atom PDF