Configuring TC redundancy parameter?

[chris -]

Hello all,

I'm running olsrd v 0.6.1 on openwrt. I set TcRedundancy=0 in the
olsr.conf.base and got a message like: "Sorry, tc-redundancy 0/1 are not
working on 0.5.6. It was discovred late in the stable tree development and
cannot bes olved without a difficult change in the dijkstra code ... ".
Then olsrd exited. I notice that TcRedundancy=2 works. Also, if
TcRedundancy is unspecified, olsrd starts with no problem.

Has this been fixed in the latest version or are there plans to fix it?
Also, could someone point me to the relevant route calculation section of
the code of the code?

Thanks in advance for any help!
Chris Patton

[Saverio Proto]

Hello,

i Cc: olsrd-dev mailing list

Saverio

Post by chris -
Hello all,
I'm running olsrd v 0.6.1 on openwrt. I set TcRedundancy=0 in the
olsr.conf.base and got a message like: "Sorry, tc-redundancy 0/1 are not
working on 0.5.6. It was discovred late in the stable tree development and
cannot bes olved without a difficult change in the dijkstra code ... ". Then
olsrd exited. I notice that TcRedundancy=2 works. Also, if TcRedundancy is
unspecified, olsrd starts with no problem.
Has this been fixed in the latest version or are there plans to fix it?
Also, could someone point me to the relevant route calculation section of
the code of the code?
Thanks in advance for any help!
Chris Patton
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users

[Henning Rogge]

Post by Saverio Proto
Hello,
i Cc: olsrd-dev mailing list
Saverio

Post by chris -
Hello all,
I'm running olsrd v 0.6.1 on openwrt. I set TcRedundancy=0 in the
olsr.conf.base and got a message like: "Sorry, tc-redundancy 0/1 are not
working on 0.5.6. It was discovred late in the stable tree development and
cannot bes olved without a difficult change in the dijkstra code ... ". Then
olsrd exited. I notice that TcRedundancy=2 works. Also, if TcRedundancy is
unspecified, olsrd starts with no problem.

Yes, TCRedundancy's default is 2. That is the only combination that
works in all cases in OLSRv1.

Post by Saverio Proto

Post by chris -
Has this been fixed in the latest version or are there plans to fix it?

No.

It will be fixed in OLSRv2, but nobody has spent effort to do it in our
OLSRv1 codebase.

Post by Saverio Proto

Post by chris -
Also, could someone point me to the relevant route calculation section of
the code of the code?

Its even more, to solve this in all cases you need
a) a link based (instead of neighbor based) 2-hop database
b) a well working MPR algorithm
c) some adaptions in the Dijkstra algorithm.

Not sure it is worth the effort.

Henning Rogge

[Henning Rogge]

Thanks very much for your reply. My thought is that using solely the MPR
set may increase reliability in our particular routing scenario, however
it would be too much work to test. It may make a good project, though.

There are two reasons why MPRs make networks unreliable with the current
implementation.

The first one is that the ETX metric tends to go up and down on all
links except the ones with no packet loss at all (see
http://en.wikipedia.org/wiki/Bernoulli_trial). This means even a totally
stable network will give you some fluctiations because you can only
measure packet loss, not the loss-probability itself.

The second one is that the current MPR algorithm is a pure greedy
algorithm, which doesn't care about the former MPR set. This means there
are situations where it will constantly switch MPR settings because of
metric fluctuations. Which will result in a more instable flooding of
control traffic.

Henning Rogge

[chris -]

Henning,

The second one is that the current MPR algorithm is a pure greedy

Post by Henning Rogge
algorithm, which doesn't care about the former MPR set. This means there
are situations where it will constantly switch MPR settings because of
metric fluctuations. Which will result in

a more instable flooding of control traffic.


This actually explains a lot. A couple questions:

(1) We were thinking it would be reasonable in our network to use only
signal level in path length calculations. Our main problem is that
fewer-hop paths are preferred, even if they use a weak,
geographically-separated link. This results in enormous losses for us. Is
this tunable or does it require a rewrite? I've notice that ETX has become
the default link-sensing metric.

(2) Perhaps to stabilize the MPR selection, it would suffice to calculate
link quality over a longer period of time. As most of our nodes aren't
mobile and are always up, this would make sense. What do you think?

Thanks for your help!

Chris Patton

[Saverio Proto]

Post by chris -
(1) We were thinking it would be reasonable in our network to use only
signal level in path length calculations. Our main problem is that fewer-hop
paths are preferred, even if they use a weak, geographically-separated link.
This results in enormous losses for us. Is this tunable or does it require a
rewrite? I've notice that ETX has become the default link-sensing metric.

Hello,
we have similar problems in Ninux

we use:
LinkQualityAlgorithm "etx_float" (instead of etx_ff)
LinkQualityAging 0.02 (that is used only with etx_float)

and then on the weak geographically-separated link we configure

LinkQualityMult 0.3

Saverio

[chris -]

Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

Thanks,
Chris

Post by chris -

Post by chris -
(1) We were thinking it would be reasonable in our network to use only
signal level in path length calculations. Our main problem is that

fewer-hop

Post by chris -
paths are preferred, even if they use a weak, geographically-separated

link.

Post by chris -
This results in enormous losses for us. Is this tunable or does it

require a

Post by chris -
rewrite? I've notice that ETX has become the default link-sensing metric.

Hello,
we have similar problems in Ninux
LinkQualityAlgorithm "etx_float" (instead of etx_ff)
LinkQualityAging 0.02 (that is used only with etx_float)
and then on the weak geographically-separated link we configure
LinkQualityMult 0.3
Saverio

[Saverio Proto]

Post by chris -
Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?

I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)

Saverio

[Henning Rogge]

Maybe we should talk about "Metric Postprocessing" on the WCW in Berlin...

an optional layer to modify metric values before they are pushed into
TCs and Hellos.

Henning

Post by Saverio Proto

Post by chris -
Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio
--
Olsr-dev mailing list
https://lists.olsr.org/mailman/listinfo/olsr-dev

[chris -]

Is that a conference? This seems like a good application for machine
learning :)

I've been thinking about OLSR a lot for the last couple months. I just got
accepted into a Masters program and am thinking for ideas for a project. I
would certainly like to keep up with peoples' experiences with olsrd and
mesh networking in general. Any pointers for me?

Chris

Post by Henning Rogge
Maybe we should talk about "Metric Postprocessing" on the WCW in Berlin...
an optional layer to modify metric values before they are pushed into
TCs and Hellos.
Henning

Post by Saverio Proto

Post by chris -
Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio
--
Olsr-dev mailing list
https://lists.olsr.org/mailman/listinfo/olsr-dev

--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

[Henning Rogge]

Post by chris -
Is that a conference? This seems like a good application for machine
learning :)

http://wiki.freifunk.net/Wireless_Community_Weekend_2013

Post by chris -
I've been thinking about OLSR a lot for the last couple months. I just got
accepted into a Masters program and am thinking for ideas for a project. I
would certainly like to keep up with peoples' experiences with olsrd and
mesh networking in general. Any pointers for me?

Most of the "large changes" will happen in the OLSRv2 software in the
future I think... noone wants to change the OLSRv1 code that much
anymore.

Henning


--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

[chris -]

Thanks for the tip. It's a shame it's so close, I would have loved an
excuse to plan a trip to my favourite city.

Post by Henning Rogge

Post by chris -
Is that a conference? This seems like a good application for machine
learning :)

http://wiki.freifunk.net/Wireless_Community_Weekend_2013

Post by chris -
I've been thinking about OLSR a lot for the last couple months. I just

got

Post by chris -
accepted into a Masters program and am thinking for ideas for a project.

I

Post by chris -
would certainly like to keep up with peoples' experiences with olsrd and
mesh networking in general. Any pointers for me?

Most of the "large changes" will happen in the OLSRv2 software in the
future I think... noone wants to change the OLSRv1 code that much
anymore.
Henning
--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

[Jeremy Lakeman]

So how is this mythical, solves world peace, OLSRv2 shaping up?

Post by Henning Rogge

Post by chris -
Is that a conference? This seems like a good application for machine
learning :)

http://wiki.freifunk.net/Wireless_Community_Weekend_2013

Post by chris -
I've been thinking about OLSR a lot for the last couple months. I just

got

Post by chris -
accepted into a Masters program and am thinking for ideas for a project.

I

Post by chris -
would certainly like to keep up with peoples' experiences with olsrd and
mesh networking in general. Any pointers for me?

Most of the "large changes" will happen in the OLSRv2 software in the
future I think... noone wants to change the OLSRv1 code that much
anymore.
Henning
--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
--
Olsr-dev mailing list
https://lists.olsr.org/mailman/listinfo/olsr-dev

[Henning Rogge]

I think you will hear a status update about it in the next 2-3 days... ;)

Henning Rogge

On Fri, May 10, 2013 at 1:02 AM, Jeremy Lakeman

Post by Jeremy Lakeman
So how is this mythical, solves world peace, OLSRv2 shaping up?

Post by Henning Rogge

Post by chris -
Is that a conference? This seems like a good application for machine
learning :)

http://wiki.freifunk.net/Wireless_Community_Weekend_2013

Post by chris -
I've been thinking about OLSR a lot for the last couple months. I just got
accepted into a Masters program and am thinking for ideas for a project. I
would certainly like to keep up with peoples' experiences with olsrd and
mesh networking in general. Any pointers for me?

Most of the "large changes" will happen in the OLSRv2 software in the
future I think... noone wants to change the OLSRv1 code that much
anymore.
Henning
--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
--
Olsr-dev mailing list
https://lists.olsr.org/mailman/listinfo/olsr-dev

[chris -]

Yes, that's what I mean. It's a shame it's not available.

Post by Saverio Proto

Post by chris -
Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio

[chris -]

Sorry about all the reposts. A question: where can I find a detailed
description of the link state calculation performed by OLSR?

Post by chris -
Yes, that's what I mean. It's a shame it's not available.

Post by Saverio Proto

Post by chris -
Saverio, that's helpful advice. I also was able to look up how these two
algorithms work. One thing: is there a parameter for hop cost?

do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio

[Saverio Proto]

Post by Saverio Proto
do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio

please look at this branch:
https://github.com/zioproto/olsrd/commits/lq-fixed-metric

there is a new parameter LinkLossFixed

there is for sure a lot of bugs still to fix :)

ciao :)

Saverio

[chris -]

Thanks!

Post by Saverio Proto

Post by Saverio Proto
do you mean a parameter to have a static hop cost between two nodes
regardless of any ETX statistic ?
I wish we had it instead of LinkQualityMult ! We actually started some
experimental work at ninux but it is not trivial at all to implement
it :)
Saverio

https://github.com/zioproto/olsrd/commits/lq-fixed-metric
there is a new parameter LinkLossFixed
there is for sure a lot of bugs still to fix :)
ciao :)
Saverio

[Michel Blais]

Hi Chris,

For link that will often have lost or that we want to use as backup, we
use LinkQualityMult to make the cost of the link higher.

Post by chris -
Henning,
The second one is that the current MPR algorithm is a pure greedy
algorithm, which doesn't care about the former MPR set. This means
there are situations where it will constantly switch MPR settings
because of metric fluctuations. Which will result in
a more instable flooding of control traffic.
(1) We were thinking it would be reasonable in our network to use only
signal level in path length calculations. Our main problem is that
fewer-hop paths are preferred, even if they use a weak,
geographically-separated link. This results in enormous losses for us.
Is this tunable or does it require a rewrite? I've notice that ETX has
become the default link-sensing metric.
(2) Perhaps to stabilize the MPR selection, it would suffice to
calculate link quality over a longer period of time. As most of our
nodes aren't mobile and are always up, this would make sense. What do
you think?
Thanks for your help!
Chris Patton