<div><div dir="auto">Well for me the question is more, which parameters can I play with in order to affect the propagation?</div></div><div dir="auto"><br></div><div dir="auto">I have a scenario where I have two P2P links. One is 5 GHz and the backup. The other 60 GHz and primary. 60 GHz can deteriorate quickly in rain, etc. This can be clearly seen from the bitrate and signal strength. It would be desirable that in this case a quick switch between those links occured.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Wolfgang</div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, 18 Aug 2018 at 18:55, Henning Rogge <<a href="mailto:hrogge@gmail.com">hrogge@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">*looking puzzled at the message*<br>
<br>
it means (as you expected) that there are additional factors delaying<br>
the change of a link, even on the directly involved pair of nodes.<br>
<br>
the question is "is it a good thing to react to quickly" and "how to<br>
determine if this is a long term trend in the link quality compared to<br>
a short glitch".<br>
<br>
Henning<br>
On Sat, Aug 18, 2018 at 6:38 PM Wolfgang Nagele <<a href="mailto:mail@wnagele.com" target="_blank">mail@wnagele.com</a>> wrote:<br>
><br>
> Part of the message missing at the end?<br>
><br>
> Cheers,<br>
> Wolfgang<br>
> On Sat, Aug 18, 2018 at 5:02 PM Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>> wrote:<br>
> ><br>
> > On Sat, Aug 18, 2018 at 8:02 AM Wolfgang Nagele <<a href="mailto:mail@wnagele.com" target="_blank">mail@wnagele.com</a>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > I've been testing a setup with two VMs. Both of them running two Layer<br>
> > > 2 links (IPv6 only) to each other. Very straight forward. To simulate<br>
> > > a link quickly dropping in quality I used the telnet Plugin to set the<br>
> > > rx_bitrate and tx_bitrate parameters.<br>
> > ><br>
> > > I noticed however that this takes about 30 seconds to take effect and<br>
> > > traffic switching to the other link. This is *much* longer than I<br>
> > > would expect for OLSR to react to a link quality change. Are there<br>
> > > config parameters that should be adjusted here? Changing the<br>
> > > hello_interval down to 0.1 reduces this time to about 5 seconds -<br>
> > > which is much better but still fairly slow.<br>
> ><br>
> > Typically the ff_dat metric averages the frame loss estimation over 32<br>
> > hello-intervals (which is a compile-time constant).<br>
> ><br>
> > This is because the loss of a few hellos could both mean a bad link or<br>
> > just bad luck.<br>
> ><br>
> > In larger networks the TC interval also plays an important roll to<br>
> > transport the link-metric change to the rest of the network.<br>
> ><br>
> > Which means<br>
</blockquote></div></div>