[Olsr-dev] Freifunk Testing
L. Aaron Kaplan
Sun Jun 15 01:15:06 CEST 2008
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
> 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.
> 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
> 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.
More information about the Olsr-dev