<br><br><div class="gmail_quote">On Sun, Aug 9, 2009 at 9:15 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<br>
<br>
I had a huge cleanup session for the OLSRd development code yesterday and<br>
discovered something BAD... something that might go back to the original OLSRd<br>
code from the diploma thesis of Andreas Toennesen (I tracked it back to the<br>
initial checkin in the olsr-ng mercurial repository in September 2004).<br>
<br>
OLSRd has the timing configuration for HNA/MID/TCs for each interface, which<br>
does not make really sense because this messages are flooded, so interfaces<br>
"configured slow" will still get messages from faster interfaces through<br>
flooding.</blockquote><div>Yes it has not much sense, so afaik we talked about changing this, even as we didn`t know how much traffic we could save doing so,...</div><div></div><div>i guess in vienna we have an average number of interfaces of about 2 (some with only one, many with 2 interfaces, some with more interfaces), so we would save araound 50% of traffic.</div>
<div><br>a bigger difference will be with hna announces,  if i currently dump for hna messages from one of our 4 gateways i get about 60 per minute instead of 12 ( = 4 gateways * 3 hnas per minute (configured hna interval there is 20 seconds))</div>
<div>as our gateways have more interfaces than average nodes.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
The really bad thing is that each of the messages send out through the<br>
multiple interfaces has it's own message sequence number !<br>
<br>
So OLSRd is NOT sending a common flooded information through all of it's<br>
interfaces, it's sending different messages, sometimes with slightly different<br>
content through the interfaces. This means that a node with 4 interfaces<br>
produce FOUR TIMES as much TCs/MIDs/HNAs per timeslot than anyone thought,<br>
which are a horror for duplicate detection and network load.<br>
<br>
The sollution in the development branch is to pull the timing parameters into<br>
the global section (out of the interfaces) and have one global timer for TCs,<br>
one for HNAs and one for MIDs which send messages through ALL of the nodes<br>
interfaces.</blockquote><div>it would be only a minimal change to exisiting gui configurations, as they (afaik) also use only one timing for all interfaces, but write it multiple times into the generated config.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Do we want this change backported into the stable branch ? I think yes. </blockquote><div>Yes *g </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">But how shall we do it without breaking too much stuff ? Do you think it's enough<br>

to have a "sane" TC/MID/HNA timing default and just ignore the settings in the<br>
interfaces ? </blockquote><div>this may be desireful for many insane settings out there, but i think it`s too bad to do so,..</div><div>.</div><div>i would let the first interface-timing settings configured in olsrd.conf overrule all other interfaces. This would in most cases lead to the completely same timings as an old olsr would have with this config file,.. (as most configs contain same timings for all interfaces)</div>
<div>.</div><div>and maybe integrate the interfaceunspecific timing options like in the tiptip already in 0.5.6</div><div>which if they are used, will overrule all timings in interface blocks</div><div></div><div>Markus</div>
</div>