[Olsr-users] Optimal OLSR config file settings

[Markus Kittenberger]

another question, do all your nodes have the same/simlar configs (especially
regarding olsr message validity times and intervals?)

and what Hello/TC/MID/HNA timeouts and intervals do you use?

On Tue, Feb 9, 2010 at 10:18 PM, Randy Buck <(spam-protected)> wrote:

> Whatever packets are getting lost are indeed going only one hop.  I set up
> tcpdump to monitor UDP packets on port 698 going out machine A to machine
> B.  I filtered it such that I only saw packets from machine A on both
> machines.  The result was, some packets going out A aren't getting to B.
>
if it just "some" packets, everything is fine,..

there are no retransmits for broadcast messages, so they are expected to be
lost
as long as e.g less than halve of the packets are lost, everything is
fine,...  (with adequate settings)

sure (-;
packets are always lost on their last hop (-;

but olsrd forwards messges from more distant nodes, and the more hops they
are forwarded, the bigger the chance that they are lost,..

with typical settings (validity times of messages several times bigger than
message interval) a lost packet (containing multiple messages from different
olsr nodes) is no big tragedy for olsrd (at least if this message didnt
contain informations about dramatic changes, than its a temporary small
tragedy,...)

but loosing consecutively multiple messages from a node (will cause
problems) as the information that this node exists will simple timeout
(based on the validity time of the message)

if such timeouts happen (due to not enough messages making their way to your
olsrd node) you will suffer from missing routes,.

and here is where the txtinfo output (with timeout information) comes in, it
shows you how long olsrds topology data is still valid. usually (in a
working network) this should be (for all entries) far greater than 50% of
the validity time of the tc or mid/hna

>
>
>> there is an compile time paramet in olsrd, that can show the validity
>> times of all topology dat in the txtinfo-plugin,..
>>
>> i recommend that you have a look at this, to find out what information
>> times out regulary, then you know where you have to change your settings
>>
>
> How is information timing out going to help?
>

see above,..
(it will help as u know what is timing out, and as u change settings gives u
feedback if this helps,..)

>
>
>>
>> to activate this change follwing in lib/txtinfo/src/olsrd_txtinfo.h
>> /* uncomment this to include VTime values into Link/Topology command */
>> /* #define ACTIVATE_VTIME_TXTINFO */
>>
>> Looking into this.
>
>
>
>> regards Markus
>>
>> On Tue, Feb 9, 2010 at 8:59 PM, Randy Buck <(spam-protected)>wrote:
>>
>>> Dear list (impersonal, yet true),
>>>
>>> We have been working with OLSR for some time now and have come up with
>>> the following problem:
>>>
>>> OLSR loses routes when traffic other than the OLSR packets is on the
>>> network.  Our OLSR packets (UDP port 698) are being prioritized over all
>>> other traffic; this doesn't help.  We suspect the OLSR packets are colliding
>>> with other packets in the air.
>>>
>>> With this in mind, we experimented with changing the HelloInterval to a
>>> really short time (0.5 sec) and the HelloValidityTime correspondingly (5
>>> sec).  We had the equation HelloValidityTime = HelloInterval * LQWindowSize
>>> in mind when setting these values.  We assume the LQ window size is 10.  As
>>> a side note, we know that LQ window size has been replaced by other
>>> settings, but don't know how it has been changed or to what it has been
>>> changed to.  If anyone can shed light on that, we would appreciate it. The
>>> idea here is that if we send more packets in a shorter time, while we will
>>> still lose packets once in a while, more will get through in the long run.
>>>
>>> Getting back to the problem, we are wondering if there are known
>>> "optimal" settings for these types of fields in the config file.  We would
>>> like to overcome the fact that some OLSR packets will be dropped due to
>>> things like the hidden node problem.
>>>
>>> Thanks,
>>>
>>> Randy Buck
>>>
>>> --
>>> Olsr-users mailing list
>>> (spam-protected)
>>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20100210/c907f608/attachment.html>