差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录 前一修订版 后一修订版 | 前一修订版 | ||
| digi:rf-wireless:xbee:zigbee:antai-dongtaitiaojie [2021/07/06 11:53] – robin | digi:rf-wireless:xbee:zigbee:antai-dongtaitiaojie [2021/07/07 14:14] (当前版本) – robin | ||
|---|---|---|---|
| 行 1: | 行 1: | ||
| - | ==== ACK Disable量化测试结果和动态调节建议==== | + | ==== 动态调节数据上报时间间隔的方案建议==== |
| **网络数据上报时间调节方法：(20210706修订）** | **网络数据上报时间调节方法：(20210706修订）** | ||
| 行 5: | 行 5: | ||
| 本方案主要在协调器端程序做一些改动，原路由器程序无需变动。 | 本方案主要在协调器端程序做一些改动，原路由器程序无需变动。 | ||
| - | RRI（0xA1）每十分钟个数算是一种网络拥堵指标。RRI的增减趋势称为busyIndex，每十分钟统计一次值并和之前值比大小，如果大则busyIndex+1, | + | 实施本方案之前是静态方案，其中K-Interval和D-Interval分别代表心跳和数据的时间间隔（以秒计）。上位机可设置心跳包和数据包的上报时间间隔，比如41: |
| + | |||
| + | 动态调节的目标是取代手动设置这两个值，自动实现网络拥堵时扩大上报间隙，网络畅通时减少上了间隙，以更快获取数据。 | ||
| + | |||
| + | RRI（0xA1）每十分钟个数RRInumber算是一种网络拥堵指标。本方案以10分钟内的RRI个数和CTS个数作为指标，即RRInumber和CTSnumber, | ||
| + | |||
| + | RRI的增减趋势称为busyIndex，每十分钟统计一次RRInumber值并和之前值比大小，如果大则busyIndex+1, | ||
| BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。也可以就以正负N为上下限。当busyIndex到达上限时（一般不可能），同样广播调节指标K-Interval+2/ | BusyIndex需要设置一个上限和下限，到达上下限时清0，以防止这个变量溢出。也可以就以正负N为上下限。当busyIndex到达上限时（一般不可能），同样广播调节指标K-Interval+2/ | ||
| 行 11: | 行 17: | ||
| 默认上电的调节指标目前测试下来41/ | 默认上电的调节指标目前测试下来41/ | ||
| - | 考虑到RRI在网络已经严重堵塞时趋势并不一定有变化，因此还要引入另一个高权值变量，即CTS变高的flag。当10分钟内两次检查到CTS变高，和BusyIndex超N作一样应对处理，即广播调节指标K-Interval+2/ | + | 考虑到RRI在网络已经严重堵塞时趋势并不一定有变化，因此还要引入另一个高权值变量，即CTS变高的次数CTSnumber。每当CTS变高，记录CTSnumbr+1, |
| + | {{: | ||
| - | 综上： 程序每10分钟统计读取RRI个数或CTS变高个数，如果CTS变高达两次，心路数据上报时间各扩大2秒。如果RRI连续5次为增量，即BusyIndex累计到5，同样心跳数据上报间隔时间各扩大2秒，直到上限不到增。 反之如果RRI是减量的，即BusyIndex为负，则心跳数据上报时间间隔各减少2秒，直到下限不再减。 | + | 综上： 程序每10分钟统计读取RRI个数或CTS变高个数，如果CTS变高达N次，心路数据上报时间各扩大2秒。如果RRI连续N次为增量，即BusyIndex累计到N，同样心跳数据上报间隔时间各扩大2秒，直到上限不到增。 反之如果RRI是减量的，即BusyIndex为负，则心跳数据上报时间间隔各减少2秒，直到下限不再减。间隔变动后，CTSnumber和BusyIndex复位为0。CTSnumber和BusyIndex取或就可以了，不必重复比较。 |
| + | |||
| + | 上位机必须可以设置N的值，以便灵活适当不同场景，如果N在上位机没有设置，可用默认值5. N可以作为BusyINdex或CTSnumber的上限。 | ||
| **原理分析** | **原理分析** | ||
| 行 20: | 行 29: | ||
| - | |||
| - | **附：07－01测试结果** | ||
| - | |||
| - | 今天主要做了Disable ACK的测试，效果远好于默认开ACK的方式。考虑到你们昨天晚上有临时开一下ACK效果不佳的情况，很可能是种意外，可进一步观察。\\ | ||
| - | 测试的目标是观察RRI指标是否可以在某种调节模式下变好，也即RRI不会越来越差，这样CTS才有可能避免拉高。\\ | ||
| - | |||
| - | 今天的测试结果和指标：\\ | ||
| - | 共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事件不会发生。 | ||