[Olsr-users] Slow reaction to change in bitrate/signal changes

[Henning Rogge]

*looking puzzled at the message*

it means (as you expected) that there are additional factors delaying
the change of a link, even on the directly involved pair of nodes.

the question is "is it a good thing to react to quickly" and "how to
determine if this is a long term trend in the link quality compared to
a short glitch".

Henning
On Sat, Aug 18, 2018 at 6:38 PM Wolfgang Nagele <(spam-protected)> wrote:
>
> Part of the message missing at the end?
>
> Cheers,
> Wolfgang
> On Sat, Aug 18, 2018 at 5:02 PM Henning Rogge <(spam-protected)> wrote:
> >
> > On Sat, Aug 18, 2018 at 8:02 AM Wolfgang Nagele <(spam-protected)> wrote:
> > >
> > > Hi,
> > >
> > > I've been testing a setup with two VMs. Both of them running two Layer
> > > 2 links (IPv6 only) to each other. Very straight forward. To simulate
> > > a link quickly dropping in quality I used the telnet Plugin to set the
> > > rx_bitrate and tx_bitrate parameters.
> > >
> > > I noticed however that this takes about 30 seconds to take effect and
> > > traffic switching to the other link. This is *much* longer than I
> > > would expect for OLSR to react to a link quality change. Are there
> > > config parameters that should be adjusted here? Changing the
> > > hello_interval down to 0.1 reduces this time to about 5 seconds -
> > > which is much better but still fairly slow.
> >
> > Typically the ff_dat metric averages the frame loss estimation over 32
> > hello-intervals (which is a compile-time constant).
> >
> > This is because the loss of a few hellos could both mean a bad link or
> > just bad luck.
> >
> > In larger networks the TC interval also plays an important roll to
> > transport the link-metric change to the rest of the network.
> >
> > Which means