<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Op 10 jan. 2013, om 18:27 heeft Michel Blais het volgende geschreven:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I know it can be use by other network
than adhoc. We use it with success over a fixed wirless network
including wired part of the network.<br></div></div></blockquote><div>Sure, OLSR runs over whatever link, as long as it supports IP.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
<br>
To explain a little we're a WISP covering rural area. Some of our
main backhaul use 24 Ghz frequency heavilly affected by rain. When
it happen, olsr will flap a lot between this link and backup link
since without traffic on the link, when olsr route the traffic on
a other link, it don't have any lost so will try back this link
again.</div></div></blockquote><div>Would the link be overloaded? Why is the link metric influenced by user traffic? I assume you use ETX.</div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix"> We need to disable those link manually for now so what we
was thinking was to make a plug-in that would check link signal
via SNMP, check more often if signal is over a first threshold and
cut it if signal is over a second threshold. Since you can't
remove a interface from olsr without restarting it, we we're
thinking about blocking via iptables olsr paquet (in and out).<br></div></div></blockquote><div>The trick is using link metrics, I think. You could try the old link-cost implementation (didn't made it in olsrd). Or use the new L2 link metric. This one uses wifi driver info. Adjusting for SNMP would be possible.</div><div><br></div><div>I'm pretty sure Henning would point to DLEP. Not available today. But yet, this is definitely the long term direction.</div><div><br></div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
<br>
The other thing was for QoS. What we was thinking was that OLSR
could drop traffic shapping over a link until the're no lost on
this link. With olsr paquet priorised, that would mean that every
traffic priorised like VoIP would also don't have any lost and
bulk taffic over traffic shapping could be drop by the router
instead of send it via the wireless link and affecting latency.
This plugin should also have a treshold that if traffic shapping
goes lower than this treshold, link should be disable instead and
a alert should be send.<br></div></div></blockquote>So your radio doesn't support QoS packet scheduling? And you want the router to do it as front-end? The IETF DLEP proposal has some mechanisms for it. But the radio must provide the feedback, e.g. queue depth or flow control.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
<br>
I know Markus mentionned on this list that it's possible to
priorise olsr paquet without using traffic shapping to have full
throughput of the link but in our case, router and wireless link
are not on the same device, it's impossible to change QoS rule on
those wireless link and latency is more important than throughput.<br></div></div></blockquote><div>If it is a fixed rate radio, it is easy to set up a shaper on your router. If rate is dynamic, but rather slow, you could set up some scripts for dynamic adjustments.</div><div><br></div>Teco</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
<br>
If the community want to do it, we could send a donation to the
project (even if I don't see any way to do it on the web page)
instead of paying dev for those plug in.<br>
<br>
Le 2013-01-10 11:35, Ben West a écrit :<br>
</div>
<blockquote cite="mid:CADSh-SP6njowanaqXfrbtXXABw4RtScjhbH98D09WvY74eq8fw@mail.gmail.com" type="cite">OLSRd can (and has been) used in media besides adhoc
802.11 wireless networks. Conceivably, one could use it on wired
transport layers like a coaxial cable network, old-school "thick"
Ethernet with vampire taps, and possibly even CAN.<br>
<br>
(Meaning there may be segments of the OLSRd community who would
find the plugins useful.)<br>
<br>
Are there any details about the desired features of the plugins
you are willing to share publicly?<br>
<br>
<div class="gmail_quote">
On Thu, Jan 10, 2013 at 8:59 AM, Michel Blais <span dir="ltr"><<a moz-do-not-send="true" href="mailto:michel@targointernet.com" target="_blank">michel@targointernet.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
We are looking for a dev that could make us 2 custom olsrd
plug-in for our network.<br>
<br>
Those plug-in would be useless for olsrd community since not
for ad-hoc network.<br>
<br>
Of course, we would pay for the work.<br>
<br>
If somebody interessted, please contact me outside of the
list.<br>
<br>
Thanks<span class="HOEnZb"><font color="#888888"><br>
<br>
Michel<br>
<br>
-- <br>
Olsr-users mailing list<br>
<a moz-do-not-send="true" href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
<a moz-do-not-send="true" href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>Ben West</div>
<div><a moz-do-not-send="true" href="mailto:me@benwest.name" target="_blank">me@benwest.name</a></div>
</blockquote>
</div>
-- <br>Olsr-users mailing list<br><a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>https://lists.olsr.org/mailman/listinfo/olsr-users</blockquote></div><br></body></html>