[Olsr-users] Problems with OLSR

[Kim Hawtin]

Hi Gian,

Gian Maria Giani wrote:
> The whole network contain 10 nodes in fixed positions, in outdoor
> environment, using olsrd v.0.4.10. Each node has about 3 neighbours, and
> the maximum distance between nodes is 3 hops. The problem we experienced
> is that routes are not stable.
> 
> This seems related to the fact that some neighbours are listed as
> non-symmetric (they appear as symmetric for some moments, then appear as
> asymmetric, then again as symmetric). The percentage of lost packets
> over these asymmetric links, however, is 0% in both directions. In the
> past weeks we have made several tries (modifying the validity and
> emission time of Hello and Tc messages, using link quality and
> hysteresis, etc), but the routes are still unstable using these
> modifications.

Can you expand on what you did with the UseHysteresis, Pollrate,
LinkQualityLevel and TcRedundancy settings?

I notice below that you have not set Hysteresis or LQ or TC...

> We have then decided to make further tests with a subset of this
> network, with only three nodes. The situation in this case is better,
> but routes are still *not* stable even in this small network. We
> observed the routes for about 20 seconds each time. With a total number
> of 68 observations, routes have been changed 10 times, which means 14.7%
> of the times. When we ran ping among nodes the percentage of lost
> packets is 0%, but the round trip time varies from 1 ms to 45 ms.
> 
> Attached to this message you can find the output of commands iptable, ip
> and iwconfig on the three nodes, as well as the contents of the
> olsrd.conf file. A few small notes: we have copied the *current*
> contents of the olsrd.conf file but, as mentioned previously, we have
> already tried different configurations, including LQ. The network nodes
> are Linux boxes using a small Linux image derived from OpenWrt, where
> only a few packages are installed and sometimes with limited options (in
> particular, this is relevant for the ip package, as you can see in the
> attached text files).
> 
> In this phase of our work, we would like to find measures for improving
> link stability, e.g. by using directional antenna, higher antenna gain,
> better interference protection, etc, but staying with olsrd 0.4.10. Do
> you have any hits on how to achieve high link stability, including both
> hardware and software measures? What is the main reason for the above
> described link instability problem?

> # Whether to use hysteresis or not
> # Hysteresis adds more robustness to the
> # link sensing but delays neighbor registration.
> # Used by default. 'yes' or 'no'
> 
> UseHysteresis   no

> # Link quality level
> # 0 = do not use link quality
> # 1 = use link quality for MPR selection
> # 2 = use link quality for MPR selection and routing
> # Defaults to 0
> 
> LinkQualityLevel        0
> 
> # Link quality window size
> # Defaults to 10
> 
> #LinkQualityWinSize     10
> 
> # Polling rate in seconds(float).
> # Default value 0.05 sec
> 
> Pollrate        0.05
> 
> 
> # TC redundancy
> # Specifies how much neighbor info should
> # be sent in TC messages
> # Possible values are:
> # 0 - only send MPR selectors
> # 1 - send MPR selectors and MPRs
> # 2 - send all neighbors
> #
> # defaults to 0
> 
> TcRedundancy    0

regards,

Kim
-- 
Operating Systems, Services and Operations
Information Technology Services, The University of Adelaide
(spam-protected)

"I am not a finite state machine"