Linux应用程序等待工位板指令应答超时500ms左右才等到应答的问题与排查
+---------------------+ +---------------------+
| | | |
| | 以太网 | |
| +---------------->+ 控制器(IP盒子) |
| Linux应用 | | |
| +<----------------+ |
| | | |
| | | |
+---------------------+ +----+-------^--------+
| | UART
v |
+-+-------+---+
| RS422 |
+--^----+-----+
| |
| | UART
+------------------+----vv+
| |
| |
| 工位板 |
| |
| |
| |
+-------------------------+
问题描述：
应用程序控制缴费机工位板的指令和缴费机回复应答的时间之间不能超过500ms, 但是搞Linux应用同事测试一段时间就会出现应答发送超时的问题
问题排查与定位：
程序打印收到上层应用的控制指令到回复上层应用应答发送完成的时间，测试得到结果显示为1ms左右即不存在超时500ms。
从物理层面检测出现超时500ms时的控制指令和应答信号之间的时间间隔：使用逻辑分析抓取两条指令的时间间隔，发现接收到控制指令到缴费机工位板发出应答300us左右。
由此可以判定发送应答超时不是工位板的问题。
控制指令数据接收和应答数据的发送都要经过控制器(类似网关)的转发，所以判断应答是控制器转发协议出现了延时。
检查控制打印的出问题时间控制指令和应答的时间间隔发现控制器的发送也不存在超时500ms左右。
协议要经过控制器(IP盒子，类似网关)通过网络发给应用，软件开发的同事怀疑是网络出现了延时。
TCP 套接字默认开启了所谓的"nagle算法"(也就是没有设置TCP_NODELAY选项)，会延缓发包时间，以便和后面（需要发送）的网络包合并在一起发送。这个算法主要用于减少网络包的数量，从而减少TCP报文头的吞吐量开销
通过wireshark抓包分析，发现出现超时延时500ms果然是网络引起的。
