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<br>
<br>Randy <br><br><div class="gmail_quote">On Wed, Dec 30, 2009 at 11:27 AM, Markus Kittenberger <span dir="ltr"><<a href="mailto:Markus.Kittenberger@gmx.at">Markus.Kittenberger@gmx.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am 30.12.2009, 18:34 Uhr, schrieb Randy Buck <<a href="mailto:sutekistudent@gmail.com" target="_blank">sutekistudent@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
Thanks for the quick reply.<br>
<br></div><div class="im">
Can you define 'G' for me.  I'm relatively new with OLSR.<br>
</div></blockquote>
*G should just be something like :-)<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
We are using version 0.5.6 r7.   I've attached three files to help with the<br>
analysis.  As you can see in the middle of routes.txt, there are several<br>
cases where a route is deleted and then added 2+ seconds later.  These<br>
</blockquote></div>
hmm this should be new enough (as no fixes in the routing code where made since than)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
files<br>
are each partials of the "sending" node in a 100 MB file transfer.  They<br>
show the topology, Dijkstra events, and Links.  The file transfer was over a<br>
"chain" starting at node 10 and ending at node 6.  The "chain" is 10 -> 11<br>
-> 12 -> 13 -> 3 -> 6.  Because we are using OLSR, this isn't necessarily<br>
the order in which packets are sent.  For example, 10 can see 11 and 12, 11<br>
can see 10, 12, and 13, etc.  There are several potential routes between<br>
nodes 10 and 6.  Let me know if you need more explanation here.<br>
</blockquote></div>
hmm so theese problem only occurs if u stress the network with an file transfer at full available speed?<br>
<br>
this may lead to big problems if you don`t have any QOS protecting olsr traffic,..<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) Why does OLSR sometimes change route when the mesh has no traffic?<br>
<br>
</blockquote>
why not?, olsrd does not care about traffic<br>
</blockquote></blockquote>
<br></div>
but unluckily this does not mean that traffic will not have side effects,..<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Coupled with issue #2 above, constantly changing routes is a problem;<br>
albeit, a small problem.<br>
</blockquote></div>
depends on what type of route change<br>
<br>
most route changes should result in no problems, or just a small tcp packet reordering<br>
<br>
but some route changes, result in packet loss (an loops), usually only theese are problems<br>
<br>
but in theory they do not happen, if no huge dramatic topology changes occure (or there are inapropriate configurations (or a bug *G))<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4) Why does OLSR change routes when it gets only a minimal cost<br>
improvement?<br>
<br>
</blockquote>
why not?, any received change is relevant, the only hysteresis in olsrd<br>
(only in new versions aswell) is done when sending packets<br>
<br>
there used to be an imcoming hysteresis aswell, but i hope no parts of it<br>
are active any more,...<br>
</blockquote>
<br>
<br>
Hysteresis is turned off.  Again, this is an issue when we have to wait 2+<br>
seconds for the route to reappear.  Can we set some sort of threshold that<br>
has to be hit before a route is considered bad/better?<br>
</blockquote></div>
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<br>
<br>
(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...<br>
<br>
such incoming stuff exists for historical reasons (but only for the default route)<br>
but in general it just makes new problems, so we better find out the cause of your problems.<br>
before trying to cure it,.. .(-;<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
The links in the above mentioned "chain" all show ETX of 1.0 when there<br>
isn't a file transfer occuring.  So I am under the assumption with that<br>
information that we have good links.<br>
</blockquote>
<br></div>
This even more sounds to me like olsr traffic is not priorized against other traffic.<br>
Am i right?<br>
<br>
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,...<br>
<br>
lg Markus<br>
</blockquote></div><br>