差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
| digi:rf-wireless:xbee:zigbee:antai-dongtaitiaojie [2021/07/06 11:51] – robin | digi:rf-wireless:xbee:zigbee:antai-dongtaitiaojie [2021/07/07 14:14] (当前版本) – robin | ||
|---|---|---|---|
| 行 1: | 行 1: | ||
| - | ==== ACK Disable量化测试结果和动态调节建议==== | + | ==== 动态调节数据上报时间间隔的方案建议==== |
| **网络数据上报时间调节方法：(20210706修订）** | **网络数据上报时间调节方法：(20210706修订）** | ||
| - | RRI（0xA1）每十分钟个数算是一种网络拥堵指标。RRI的增减趋势称为busyIndex，每十分钟统计一次值并和之前值比大小，如果大则busyIndex+1, | + | 本方案主要在协调器端程序做一些改动，原路由器程序无需变动。 |
| - | BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。也可以就以正负N为上下限。当busyIndex到达上限时（一般不可能），同样广播调节指标K-Interval+2/D-Interval+2，当busyIndex到达下限时（网络好有可能），同样广播调节指标K-Interval-2/ | + | 实施本方案之前是静态方案，其中K-Interval和D-Interval分别代表心跳和数据的时间间隔（以秒计）。上位机可设置心跳包和数据包的上报时间间隔，比如41: |
| - | 默认上电的调节指标目前测试下来41/ | + | 动态调节的目标是取代手动设置这两个值，自动实现网络拥堵时扩大上报间隙，网络畅通时减少上了间隙，以更快获取数据。 |
| - | 考虑到RRI在网络已经严重堵塞时趋势并不一定有变化，因此还要引入另一个高权值变量，即CTS变高的flag。当10分钟内两次检查到CTS变高，和BusyIndex超N作一样应对处理，即广播调节指标K-Interval+2/ | + | RRI（0xA1）每十分钟个数RRInumber算是一种网络拥堵指标。本方案以10分钟内的RRI个数和CTS个数作为指标，即RRInumber和CTSnumber, 其中RRInumber不作为直接判断网络拥堵依据，而是作为另一个趋势数据busyIndex的参考值，而CTSnumber直接作为网络拥堵的指标。 |
| - | 综上： 程序每10分钟统计读取RRI个数或CTS变高个数，如果CTS变高达两次，心路数据上报时间各扩大2秒。如果RRI连续5次为增量，即BusyIndex累计到5，同样心跳数据上报间隔时间各扩大2秒，直到上限不到增。 反之如果RRI是减量的，即BusyIndex为负，则心跳数据上报时间间隔各减少2秒，直到下限不再减。 | + | RRI的增减趋势称为busyIndex，每十分钟统计一次RRInumber值并和之前值比大小，如果大则busyIndex+1, |
| - | **原理分析** | + | BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。也可以就以正负N为上下限。当busyIndex到达上限时（一般不可能），同样广播调节指标K-Interval+2/ |
| - | 综合前几天测试的结果得出一些结论：网络拥堵时，由于协调器发过不来，实际上它发送负荷很大，以致缓冲区会慢慢增大到溢出状态，此时可见CTS拉高，使用流控来防止缓冲区溢出。当发送负荷大时，发送优先权也适当提高了，此时下面上发数据更容易发生碰撞，从而导致更不容易发通，此时MTO变多，并且协调器收到的RRI会变多。常见的NETWORK ACK Failure和TX Failure大多是这个原因。实测下来，发送选项不禁用ACK时，会导至重传多次发生并且接收端收到数据包超过发送端，而这些包在网络拥者时大多是没有意义的，反而进一步恶化网络拥堵状况。因为此时协调器应答包是入在发送缓冲区末端，所以即便有应答，也是很久之后，和10秒握手的机制不匹配。路由器收到这包理论上也是不会认为是之前应答，但不排除有时刚好在下次发送的时候收到，这也就是大网络拥堵下你们没有频繁退网的事件发生，只有偶发退网事件的原因。 | + | 默认上电的调节指标目前测试下来41/ |
| + | 考虑到RRI在网络已经严重堵塞时趋势并不一定有变化，因此还要引入另一个高权值变量，即CTS变高的次数CTSnumber。每当CTS变高，记录CTSnumbr+1, | ||
| + | {{: | ||
| + | 综上： 程序每10分钟统计读取RRI个数或CTS变高个数，如果CTS变高达N次，心路数据上报时间各扩大2秒。如果RRI连续N次为增量，即BusyIndex累计到N，同样心跳数据上报间隔时间各扩大2秒，直到上限不到增。 反之如果RRI是减量的，即BusyIndex为负，则心跳数据上报时间间隔各减少2秒，直到下限不再减。间隔变动后，CTSnumber和BusyIndex复位为0。CTSnumber和BusyIndex取或就可以了，不必重复比较。 | ||
| - | **附：07－01测试结果** | + | 上位机必须可以设置N的值，以便灵活适当不同场景，如果N在上位机没有设置，可用默认值5. N可以作为BusyINdex或CTSnumber的上限。 |
| - | 今天主要做了Disable ACK的测试，效果远好于默认开ACK的方式。考虑到你们昨天晚上有临时开一下ACK效果不佳的情况，很可能是种意外，可进一步观察。\\ | + | **原理分析** |
| - | 测试的目标是观察RRI指标是否可以在某种调节模式下变好，也即RRI不会越来越差，这样CTS才有可能避免拉高。\\ | + | |
| - | 今天的测试结果和指标：\\ | + | 综合前几天测试的结果得出一些结论：网络拥堵时，由于协调器发过不来，实际上它发送负荷很大，以致缓冲区会慢慢增大到溢出状态，此时可见CTS拉高，使用流控来防止缓冲区溢出。当发送负荷大时，发送优先权也适当提高了，此时下面上发数据更容易发生碰撞，从而导致更不容易发通，此时MTO变多，并且协调器收到的RRI会变多。常见的NETWORK ACK Failure和TX Failure大多是这个原因。实测下来，发送选项不禁用ACK时，会导至重传多次发生并且接收端收到数据包超过发送端，而这些包在网络拥者时大多是没有意义的，反而进一步恶化网络拥堵状况。因为此时协调器应答包是入在发送缓冲区末端，所以即便有应答，也是很久之后，和10秒握手的机制不匹配。路由器收到这包理论上也是不会认为是之前应答，但不排除有时刚好在下次发送的时候收到，这也就是大网络拥堵下你们没有频繁退网的事件发生，只有偶发退网事件的原因。 |
| - | 共191个节点，Disable ACK在35/ | + | |
| - | + | ||
| - | + | ||
| - | **抓包指标分析** | + | |
| - | 14：20改为41/ | + | |
| - | 测试时间：14: | + | |
| - | 测得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: | + | |
| - | 测得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: | ||
| - | 测得0xA1=5556 | ||
| - | 0xA1(MTO_AR)=5*191=955 | ||
| - | 实际0xA1=5556-955=4601 | ||
| - | RRI per second=4.73 | ||
| - | RRI per minute = 284 \\ | ||
| - | 可见，在有外部小干扰时，RRI指标仍减少，也就是网络拥堵不会进一步恶化，流控CTS事件不会发生。 | ||