Bruce Simpson wrote: > Ben Greear wrote: > >> The reset_twohop_mpr_state counts neighbors that are strict and reachable. >> But, the consider_poorly_covered method checks for reachability == 1. >> In the log below, neighbor 10.7.7.7 is not counted in poorly_covered. >> Should we maybe check for reachability() > 0 instead of == 1? >> >> > > Off the top of my head, for classical OLSR, as specified in the RFC, it > needs to be covered by a minimum of 1 neighbour, in terms of links. > I don't have the code in front of me, obviously a test of reachability > == 1 would be naive. If the fix is that simple, that's great. >
I just skimmed this code again. Based on how I interpreted the RFC, a 'poorly covered two-hop neighbour' is indeed one which is reachable only by a single one-hop neighbour, so the reachability test 1 is fine. This is the case for classical OLSR, but not the case for ETX where the reachability has fractional dimension, and it's something the 'reachability' metric has to take into account. We could use floating point to compute this, but integer operations are generally better for performance, that's just an implementation constraint. There are places where you can't get away from using floating point. It's not that bad if the target supports IEEE 754 efficiently. An uncovered two-hop neighbour would not be considered in the MPR computation, and the existence of such would normally only be an artefact of pending updates. Jitter is usually used to avoid such situations, and isn't fully implemented in the XORP OLSR process (I did say it was unfinished work :-)). There are a number of areas where the theory doesn't meet the practice. The OLSR.org crew did do a lot of modeling work in the end, and there's places where some of the theory in the RFC falls down. cheers, BMS _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
