Hi Folks
Can somebody explain why this function works the way it does:
uint8_t ring_buffer_avg(uint8_t lq_recv[]) { uint8_t *ptr; uint16_t count = 0, i = 0, sum = 0;
ptr = lq_recv;
while (i < TQ_GLOBAL_WINDOW_SIZE) { if (*ptr != 0) { count++; sum += *ptr; }
i++; ptr++; }
if (count == 0) return 0;
return (uint8_t)(sum / count); }
It only averages over the none zero values.
The code filling these ring buffer puts a zero in whenever an originator message is received from another neighbor. When the originator message is from this neighbor, the tq in the originator message is put in.
When a neighbor is dead, the ring slowly fills with 0's, whenever there is an originator message from one of the other neighbors. However since the 0 are ignored when calculating the average, we tend to have a cliff effect for dead neighbors. There tq_avg stays about the same for quite a while, and then plummets to 0. For faster detecting dead neighbors, it would be better if the 0 were included in the average. The tv_avg would then drop more linearly, not cliff like, so it is likely to cross below another neighbors tv_avg earlier, so re-routing around the dead node faster.
Before i change this function, i just want to understand why it is like this, and what i'm likely to break :-(
Thanks Andrew
Hi,
When a neighbor is dead, the ring slowly fills with 0's, whenever there is an originator message from one of the other neighbors. However since the 0 are ignored when calculating the average, we tend to have a cliff effect for dead neighbors. There tq_avg stays about the same for quite a while, and then plummets to 0. For faster detecting dead neighbors, it would be better if the 0 were included in the average. The tv_avg would then drop more linearly, not cliff like, so it is likely to cross below another neighbors tv_avg earlier, so re-routing around the dead node faster.
this approach will penalize asymetric links. Imagine you have a link which you can use for sending very well (no packet loss) but the opposite direction is quite weak (receiving looses some packets). You need to receive the batman information over that very link to make sure the other side is still alive. May be you only get 2 out of 10 via that perfect link and the other 8 via a connection that is bad (from your standpoint). If you take the 0 into account you will use the bad link instead of the good one.
Regards, Marek
b.a.t.m.a.n@lists.open-mesh.org