[Olsr-users] OLSR Questions

[Randy Buck]

We aren't prioritizing OLSR packets at all.  I'm hoping this will solve our
problems.  I've googled how to prioritize packets in the kernel using the tc
command, but am hoping there is a page you can point me to that will
expedite my searching.  Thanks

Randy

On Wed, Dec 30, 2009 at 11:27 AM, Markus Kittenberger <
(spam-protected)> wrote:

> Am 30.12.2009, 18:34 Uhr, schrieb Randy Buck <(spam-protected)>:
>
>  Thanks for the quick reply.
>>
>> Can you define 'G' for me.  I'm relatively new with OLSR.
>>
> *G should just be something like :-)
>
>
>>
>> We are using version 0.5.6 r7.   I've attached three files to help with
>> the
>> analysis.  As you can see in the middle of routes.txt, there are several
>> cases where a route is deleted and then added 2+ seconds later.  These
>>
> hmm this should be new enough (as no fixes in the routing code where made
> since than)
>
>
>  files
>> are each partials of the "sending" node in a 100 MB file transfer.  They
>> show the topology, Dijkstra events, and Links.  The file transfer was over
>> a
>> "chain" starting at node 10 and ending at node 6.  The "chain" is 10 -> 11
>> -> 12 -> 13 -> 3 -> 6.  Because we are using OLSR, this isn't necessarily
>> the order in which packets are sent.  For example, 10 can see 11 and 12,
>> 11
>> can see 10, 12, and 13, etc.  There are several potential routes between
>> nodes 10 and 6.  Let me know if you need more explanation here.
>>
> hmm so theese problem only occurs if u stress the network with an file
> transfer at full available speed?
>
> this may lead to big problems if you don`t have any QOS protecting olsr
> traffic,..
>
>
>>
>>>
>>>  3) Why does OLSR sometimes change route when the mesh has no traffic?
>>>>
>>>>  why not?, olsrd does not care about traffic
>>>
>>
> but unluckily this does not mean that traffic will not have side effects,..
>
>
>
>> Coupled with issue #2 above, constantly changing routes is a problem;
>> albeit, a small problem.
>>
> depends on what type of route change
>
> most route changes should result in no problems, or just a small tcp packet
> reordering
>
> but some route changes, result in packet loss (an loops), usually only
> theese are problems
>
> but in theory they do not happen, if no huge dramatic topology changes
> occure (or there are inapropriate configurations (or a bug *G))
>
>
>>
>>>
>>>  4) Why does OLSR change routes when it gets only a minimal cost
>>>> improvement?
>>>>
>>>>  why not?, any received change is relevant, the only hysteresis in olsrd
>>> (only in new versions aswell) is done when sending packets
>>>
>>> there used to be an imcoming hysteresis aswell, but i hope no parts of it
>>> are active any more,...
>>>
>>
>>
>> Hysteresis is turned off.  Again, this is an issue when we have to wait 2+
>> seconds for the route to reappear.  Can we set some sort of threshold that
>> has to be hit before a route is considered bad/better?
>>
> as there is no way to ensure that this local thresholds do not sum up to
> different routing decission through the network, local hysteresis on
> imcoming data is a bad idea
>
> (btw there is already an 10% hysteresis on the lq values a node sends out)
> -> and if nothing helps we could try to change this...
>
> such incoming stuff exists for historical reasons (but only for the default
> route)
> but in general it just makes new problems, so we better find out the cause
> of your problems.
> before trying to cure it,.. .(-;
>
>
>>
>>
>> The links in the above mentioned "chain" all show ETX of 1.0 when there
>> isn't a file transfer occuring.  So I am under the assumption with that
>> information that we have good links.
>>
>
> This even more sounds to me like olsr traffic is not priorized against
> other traffic.
> Am i right?
>
> So when u have much traffic, olsr traffic gets partly discarded (by your
> routers kernel), resulting in somewhat dramatic cost changes for oslr, and
> usual undesireful behaviour of olsr in this case,...
>
> lg Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20091230/960bb69c/attachment.html>