<div>another question, do all your nodes have the same/simlar configs (especially regarding olsr message validity times and intervals?)<br></div><div><br></div><div>and what Hello/TC/MID/HNA timeouts and intervals do you use?</div>
<br><div class="gmail_quote">On Tue, Feb 9, 2010 at 10:18 PM, Randy Buck <span dir="ltr"><<a href="mailto:sutekistudent@gmail.com">sutekistudent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
</blockquote><div>if it just "some" packets, everything is fine,..</div><div><br></div><div>there are no retransmits for broadcast messages, so they are expected to be lost<br>as long as e.g less than halve of the packets are lost, everything is fine,... (with adequate settings)<br>
</div><div><br></div><div>sure (-;</div><div>packets are always lost on their last hop (-;</div><div><br></div><div>but olsrd forwards messges from more distant nodes, and the more hops they are forwarded, the bigger the chance that they are lost,..</div>
<div><br></div><div>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,...)</div>
<div> </div><div>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)</div><div><br></div><div>
if such timeouts happen (due to not enough messages making their way to your olsrd node) you will suffer from missing routes,.</div><div><br></div><div>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</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div>
<br></div><div>there is an compile time paramet in olsrd, that can show the validity times of all topology dat in the txtinfo-plugin,..</div><div><br></div><div>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</div>
</blockquote></div><div><br>How is information timing out going to help?<br></div></div></blockquote><div><br></div><div>see above,.. </div><div>(it will help as u know what is timing out, and as u change settings gives u feedback if this helps,..)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div> <br></div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><br></div><div>to activate this change follwing in lib/txtinfo/src/olsrd_txtinfo.h</div><div>/* uncomment this to include VTime values into Link/Topology command */<br>/* #define ACTIVATE_VTIME_TXTINFO */<br></div><div>
<br></div></blockquote></div><div>Looking into this.<br><br> </div><div class="im"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div>regards Markus</div>
<br><div class="gmail_quote"><div><div>On Tue, Feb 9, 2010 at 8:59 PM, Randy Buck <span dir="ltr"><<a href="mailto:sutekistudent@gmail.com" target="_blank">sutekistudent@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div>
Dear list (impersonal, yet true),<br><br>We have been working with OLSR for some time now and have come up with the following problem: <br><br>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. <br>
<br>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.<br><br>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.<br>
<br>Thanks,<br><font color="#888888"><br>Randy Buck<br>
</font><br></div></div>--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br></blockquote></div><br>
</blockquote></div></div><br>
</blockquote></div><br>