[Olsr-users] MPR Selection problem

[Scoobi Doo]

Hi,
Your answer regarding using ETX code brings me back to another problem. I don't use ETX because i'm having simulations on narrowband nodes, which force me to change the size of the MTU (from 1500 to 128). When the network gets larger and the olsrd starts to fragment the messages (serialize functions) the routing table in ETX-mode is not correct in a simple full-mesh topology. From tests that i ran i saw that no matter what is the MTU size whenever the network becomes larger so messages get fragmented, the olsrd fails to build the right routing table. When i use non-ETX code i don't see that problem.
I prefer using ETX. did you encounter in such a problem?



On Friday, October 24, 2014 11:33 AM, Henning Rogge <(spam-protected)> wrote:
 


On Fri, Oct 24, 2014 at 9:27 AM, Scoobi Doo <(spam-protected)> wrote:
> configuration: No ETX, equal Willingness=3 to all nodes, version 0.6.6.2

Don't expect support for "no etx". Its fundamentally broken for all
radio networks.


> When i run this scenario with ETX enabled i get good results (MPR selected
> and correct routes)
>
> I've tried to look into the code of the mpr selection in mpr.c and i made
> the following change:
> in the function olsr_calculate_two_hop_neighbors (line 311), i added a reset
> to the counters in the end of the main loop:
>     a_neighbor->neighbor_2_nocov = n_count;
>
>     /* Add the two hop count */
>     sum += count;
>
>   }
>   OLSR_FOR_ALL_NBR_ENTRIES_END(a_neighbor);
>
> change to:
>     a_neighbor->neighbor_2_nocov = n_count;
>
>     /* Add the two hop count */
>     sum += count;
> n_count = 0;
> count = 0;
>
>   }
>   OLSR_FOR_ALL_NBR_ENTRIES_END(a_neighbor);
>
>
> This change seems to fix the MPR problem in this scenario, my question
> (finally..) is: What does this function should return (# of strict 2-hop
> nbrs??)? Is this a bug or am i wrong?

I don't know and I wont spend time with the no-etx codepath...

in fact I think that even the ETX-MPR code is slightly broken (and
cannot be easily fixed because of missing data in the data-bases),
that is why we normally switch it of by applying a high "mpr
redundancy" value.

if you want to work on MPR code that WILL be used in the future, look
into the OLSRv2 code. I (and Jonathan Kirchhoff) would be happy to
hear feedback about the MPR plugin.

Henning Rogge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20141024/3622aed1/attachment.html>