Linux应用程序等待工位板指令应答超时500ms左右才等到应答问题(LwIP)定位排查

Linux应用在与工位板通信中遇到500ms超时问题。经排查,确定超时并非工位板或控制器问题,而是TCP协议中的Nagle算法导致的网络延时。通过Wireshark抓包证实,解决方案是在控制器代码中启用TCP_NODELAY选项以优化网络发送。
摘要由CSDN通过智能技术生成

Linux应用程序等待工位板指令应答超时500ms左右才等到应答问题(LwIP)定位排查

+---------------------+                 +---------------------+
|                     |                 |                     |
|                     |      以太网      |                     |
|                     +---------------->+     控制器           |
|       Linux应用      |                 |                     |
|                     +<----------------+                     |
|                     |                 |                     |
|                     |                 |                     |
+---------------------+                 +----+-------^--------+
                                             |       |  UART
                                             v       |
                                           +-+-------+---+
                                           |    RS422    |
                                           +--^----+-----+
                                              |    |
                                              |    |  UART
                           +------------------+----vv+
                           |                         |
                           |                         |
                           |        工位板            |
                           |                         |
                           |                         |
                           |                         |
                           +-------------------------+


问题描述:

工位板收到Linux应用指令和回复应答的时间之间不能超过500ms, 但是搞Linux应用同事测试一段时间就会出现应答发送超时的问题

问题排查与定位:

程序打印收到上层应用的控制指令到回复上层应用应答发送完成的时间,测试得到结果显示为1ms左右即不存在超时500ms。

从物理层面检测出现超时500ms时的控制指令和应答信号之间的时间间隔:使用逻辑分析抓取两条指令的时间间隔,发现工位板接收到控制指令到工位板发出应答300us左右。

由此可以判定发送应答超时不是工位板的问题。

控制指令数据接收和应答数据的发送都要经过控制器的转发,所以判断应答是控制器转发协议出现了延时。

检查控制打印的出问题时间控制指令和应答的时间间隔发现控制器的发送也不存在超时500ms左右。

协议要经过控制器通过网络发给应用,软件开发的同事怀疑是网络出现了延时。

TCP 套接字默认开启了所谓的"nagle算法"(也就是没有设置TCP_NODELAY选项),会延缓发包时间,以便和后面(需要发送)的网络包合并在一起发送。这个算法主要用于减少网络包的数量,从而减少TCP报文头的吞吐量开销

通过wireshark抓包分析,发现出现超时延时500ms果然是网络引起的。

解决:
需要修改控制器的源码将创建的TCP服务器设置TCP_NODELAY选项

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

欲盖弥彰1314

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值