[Olsr-dev] Freifunk Testing

[L. Aaron Kaplan]

On Jun 14, 2008, at 10:47 PM, elektra wrote:

> Hi -
>> btw: Is there a reason for an TC Interval of 2 at an HELLO  
>> Interval of 5? that
>> would be 2 TCs before the linkcost of a link could change...
>>
> there is. This is to avoid routing loops even when links are saturated
> with payload traffic. Not all TC updates are likely to come through
> under these circumstances, so redundancy helps here. (But even when
> sending TCs twice as frequently as Hellos,  Olsrd did loop  
> occasionally
> when we were testing it at the Meraka 'Massive Mesh' grid under high
> payload.) To get entirely rid of routing loops, TC redundancy has  
> to be
> even greater. But the resulting protocol overhead is much more severe
> then occasional routing loops that persist for a couple of seconds.  
> This
> is a limitation of the protocol design.

So basically what you are saying is "let's spam more because we can't  
hear things because we spam to much"??


>
> If you are not using Fisheye TC redundancy is of course very bad for a
> large scale network.

That is why fisheye ^H let's please call it by it's real name - Hazy  
sighted link state routing - is a good idea.
BUT at the same time - HSLS also helps in *creating* loops (quite  
logical when you think of it).

>
> Btw: There should be an option to disable the MPR algorithm  
> completely.
> It is superfluous anyway for Freifunk-like configurations since Wizard
> of OS 2004. Setting MPR redundancy to 7 in the config is just a dirty
> hack to get rid of the negative effects of  MPR selection and the
> problems that are growing out of it.

I don't quite agree here.