hmm i guess your tc-set fails to do anything useful if your link is slower than 14mbit,..<div><br></div><div>Markus<br><br><div class="gmail_quote">On Fri, Mar 30, 2012 at 9:39 AM, Michael Rack <span dir="ltr"><<a href="mailto:michael.rack@rsm-freilassing.de">michael.rack@rsm-freilassing.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Of course, my link is sometimes congested, but i don't know the
current max. bandwidth, because the link-quality is jumping, so the
bandwidth is between 5 and 15 MBit. The most of the time, stable at
15 MBit.<br>
<br>
ROUTE A have stable bandwidth at 60MBit, so i like to use ROUTE B
only for backup. But currently ROUTE B is the primary choose from
olsr.<br>
<br>
Now i will give LinkQualityMult a try.<br>
<br>
How can i reload olsrd.conf without killing and restarting olsr?<br>
Currently i always have about 10-30 sec. of downtime.<br>
<br>
<br>
To solve/minimize my "flapping" problem, i've installed a tc-rule a
long time before, because the link was allways degraded on a high
usage:<br>
<br>
<blockquote type="cite">1634K 84M MARK tcp tcp flags:0x17/0x02
mark match 0x0 MARK xset 0x1/0xffffffff<br>
76M 3790M MARK tcp tcp flags:0x10/0x10 length 0:100 mark match
0x0 MARK xset 0x1/0xffffffff<br>
3383K 1726M MARK udp udp dpt:698 mark match 0x0 MARK xset
0x2/0xffffffff</blockquote>
<br>
<blockquote type="cite">qdisc htb 1: root r2q 10 default 104
direct_packets_stat 5<br>
class htb 1:1 root rate 14000Kbit ceil 14000Kbit burst 6Kb cburst
6Kb<br>
class htb 1:101 parent 1:1 leaf 801d: prio 1 rate 200kbit ceil
14000Kbit burst 6Kb cburst 6Kb<br>
class htb 1:102 parent 1:1 leaf 801e: prio 2 rate 300kbit ceil
14000Kbit burst 4Kb cburst 4Kb<br>
class htb 1:103 parent 1:1 leaf 801f: prio 4 rate 500kbit ceil
14000Kbit burst 2Kb cburst 2Kb<br>
class htb 1:104 parent 1:1 leaf 8020: prio 7 rate 4000Kbit ceil
14000Kbit burst 1Kb cburst 1022b<br>
filter parent 1: protocol ip pref 49152 fw handle 0x1 classid
1:101<br>
filter parent 1: protocol ip pref 49151 fw handle 0x2 classid
1:102<br>
filter parent 1: protocol ip pref 49151 fw handle 0x3 classid
1:103<br>
filter parent 1: protocol ip pref 49151 fw handle 0x4 classid
1:104<br>
</blockquote>
<br>
<br>
<br>
<pre cols="72">Liebe Grüße aus Freilassing,
Michael Rack
RSM Freilassing
--
RSM Freilassing Tel.: <a href="tel:%2B49%208654%20607110" value="+498654607110" target="_blank">+49 8654 607110</a><div class="im">
Nocksteinstr. 13 Fax.: <a href="tel:%2B49%208654%20670438" value="+498654670438" target="_blank">+49 8654 670438</a>
D-83395 Freilassing <a href="http://www.rsm-freilassing.de" target="_blank">www.rsm-freilassing.de</a> </div></pre>
<br>
Am 30.03.2012 02:04, schrieb Markus Kittenberger:
<div><div class="h5"><blockquote type="cite">
<div><br>
<div class="gmail_quote">On Thu, Mar 29, 2012 at 9:40 PM, Michel
Blais <span dir="ltr"><<a 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">
This often happen when the're no traffic on A link and b
link have some paquet lost.<br>
<br>
If paquet lost for B link is too much and cost more then 3
then it will try link A. If the're no traffic on link B then
cost come back to 2 so it goes back to B.<br>
</blockquote>
<div><br>
</div>
imho first to do do solve/minimize this "flapping" problem, is
priorizing olsrd traffic so it gets as least as possible
affected by packetloss due to congestion on your links,..</div>
<div class="gmail_quote"><br>
</div>
<div class="gmail_quote">Markus<br>
<div> </div>
</div>
</div>
</blockquote>
</div></div></div>
</blockquote></div><br></div>