This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

数据发送速度变慢

Other Parts Discussed in Thread: Z-STACK

问题:从调用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。

  •  你好,

    是通过I/O的翻转来测试t1和t2时间的吗?t1, t2是怎么测试的

    在收到confirm以后,也就是t2以加一段时间的delay,不影响测试t1+t2的值,是否还会出现该情况。

    你程序里面end device的data Request的周期是多少?

  • 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的操作似乎都是在库中完成,不可见,说明也很少,不知究竟有什么作用。虽然这样修改后工作正常,但是否会有其他影响,心里有点没底。

  • 回复zhou chen1:

    你好,我也遇到同样的问题了,通信变卡顿,我想问下,你说的手动将AssociatedDevList[0].linkInfo.txCost改为0x01,是指在协调器里改,还是终端改呢?