网络数据上报时间调节方法：

RRI每十分钟个数算是一种网络拥堵指标，称为busyIndex，每十分钟统计一次值并和之前值比大小，如果大则busyIndex+1, 如果小则busyIndex-1，当busyIndex>10时，广播调节指标Kinterval+2/Dinterval+2 ，当busyInex←10时，广播调节指标Kinterval-2/Dinterval-2。

BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。

网络拥堵时，由于协调器发过不来，实际上它发送负荷很大，以致缓冲区会慢慢增大到溢出状态，此时可见CTS拉高，使用流控来防止缓冲区溢出。当发送负荷大时，发送优先权也适当提高了，此时下面上发数据更容易发生碰撞，从而导致更不容易不通。常见的NETWORK ACK Failure和TX Failure大多是这个原因。实测下来，发送选项不禁用ACK时，会导至重传多次发生并且接收端收到数据包超过发送端，而这些包在网络拥者时大多是没有意义的，因为此时协调器应答包是入在发送缓冲区末端，所以即便有应答，也是很久之后，和10秒握手的机制不匹配。路由器收到这包理论上也是不会认为是之前应答，但不排除有时刚好在下次发送的时候收到，这也就是大网络拥堵下你们没有频繁退网的事件发生，只有偶发退网事件。

今天主要做了Disable ACK的测试，效果远好于默认开ACK的方式。考虑到你们昨天晚上有临时开一下ACK效果不佳的情况，很可能是种意外，可进一步观察。

今天的测试结果和指标：

共191个节点，Disable ACK在35/50的指标下工作正常，也就是35秒心跳，50秒数据这个上报间隔。在40/80对RRI的抓取结果显示，其RRI每分钟个数为284，效果比之前好一倍。从数据上线来看，在35/50上也是非常好的。

14：20改为41/80， 14：29记录15分钟

测试时间：14:29:07~14:44:37, 共15分30秒 =930S
测得0xA1=5134
0xA1(MTO_AR)=5*191=955
实际0xA1=5134-955=4179
RRI per second=4.49
RRI per minute = 269

这个抓包在更改后不到10分钟开始，因此意义不大，过30分钟再抓一次。

测试2：改后一小时 测试时间：15:26:08~15:41:08, 共15分 =900S
测得0xA1=5207
0xA1(MTO_AR)=5*191=955
实际0xA1=5207-900=4307
RRI per second=4.78
RRI per minute = 287

RRI在上电半小时和1小时后，有些增幅，需要再测一次，如果趋势保持，说明稳态后没法消除协调器要发的数据大于能处理的数据，需要进行减少密集发送的行动，也就是增大间隔。

测试3: 注：有人到协调器边上和松讨论
测试时间：16:01:20~16:17:32, 共16分12秒 =972S
测得0xA1=5556
0xA1(MTO_AR)=5*191=955
实际0xA1=5556-955=4601
RRI per second=4.73
RRI per minute = 284

可见，在有外部小干扰时，RRI指标仍减少，也就是网络拥堵不会进一步恶化，流控CTS事件不会发生。