TI中文支持网问题：从调用AF_DataRequest到数据发出，是什么原因造成了中间有一个几百ms的延时？（而且这个延时刚开始是没有的，只有发送过100多次才会产生。）
协议栈版本 Z-Stack Home 1.2.1
一个协调器、一个终端，设备连接后，协调器连续向终端发送同一数据包（50字节用户数据），每次只有在收到上一个数据包的Confirm后，才回开始发下一数据包。
设定：一个数据包的整个发送过程，主要分以下两个时间段：
t1 —— 从协调器调用AF_DataRequest，至数据发送出去。
t2 —— 从数据发送出去，至收到终端Confirm
实际测试发现，刚开始发送时，发送一个数据包的时间（t1+t2）约50ms，主要为t2，t1极短，基本可忽略）；
但等发了100多个数据包后，时间会变长，（t1+t2）约400多ms，t2与之前基本没变化，t1变为约400ms。
之后发送数据包都是400ms，无法恢复到原先的50ms。
1、我原先以为是内存碎片造成，但调试发现alloc函数从来没有返回fail，因此排除内存碎片造成。
2、出现上述情况后，重启协调器或重启终端，发送时间都会恢复至50ms。
3、我连接两个终端（同一程序）到协调器，协调器向终端A连续发送，直至出现上述情况（发送时间变为400ms），再使协调器向终端B发送数据，发现时间正常，约50ms。即协调器向A发送需400s，向B发送只需50ms。
VV：
你好，
是通过I/O的翻转来测试t1和t2时间的吗？t1, t2是怎么测试的
在收到confirm以后，也就是t2以加一段时间的delay，不影响测试t1+t2的值，是否还会出现该情况。
你程序里面end device的data Request的周期是多少？
AndyChen：
回复 VV:
VV你好，谢谢回复。
我是通过Packet sniffer上Packet的时间戳，和串口打印显示的时间，来判断t1、t2的，虽然不如示波器精确，但通过多次的重复测试，也能够得出大概的t1、t2时间了。
关于t1时间变长的原因，我已经找到，是关联表AssociatedDevList造成的。比如：
协调器C连接有一个终端E，在未出现上述现象时，发送时间正常，t1为几个ms，此时AssociatedDevList[0].devStatus = 0x44，AssociatedDevList[0].linkInfo.txCost = 0x01。
出现上述现象后，发送时间明显边长，t1为几百ms，此时AssociatedDevList[0].devStatus = 0x46，AssociatedDevList[0].linkInfo.txCost = 0x00。此时若我在调试中暂停，手动将AssociatedDevList[0].linkInfo.txCost改为0x01，则发送时间就会恢复正常。
所以，现在我代码中在调用AF_DataRequest之前，都会做一遍将关联表所有设备的LinkInfo.txCos改为0x01。
zstack中对LinkInfo.txCos的操作似乎都是在库中完成，不可见，说明也很少，不知究竟有什么作用。虽然这样修改后工作正常，但是否会有其他影响，心里有点没底。
zexin zeng：
回复 AndyChen:
回复zhou chen1：
你好，我也遇到同样的问题了，通信变卡顿，我想问下，你说的手动将AssociatedDevList[0].linkInfo.txCost改为0x01，是指在协调器里改，还是终端改呢？
