2011/12/8 gerhard poller <span dir="ltr"><<a href="mailto:akku99@gmx.at" target="_blank">akku99@gmx.at</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 brenner 2 stunden nachdem auch lan_olsr route lauft,<br>
und alles ihmo optimiert wurde<br></blockquote><div>ALLES ? (-;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lauft schon wieder einer mit torent, 5mbit bis 500 udp adressen zugleich<br>

um vernunft bittent ist eine mail an demjenigen  schon unterwegs<br></blockquote><div>was vmtl momentan eh der zielführenste ansatz,..  (evt. in kombination mit freiwilligen 'zapp' oder dergleichen am lan interface)<br>
(aber bitte nit im forward)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
andere haben dadurch anstatt lq 0.7 NUR mehr lq 0.2<br></blockquote><div>also diese auswirkung liegt an der (für mesh einsatz) noch "unfertigen" backfire vienna firmware (auf atheros hardware),.. </div><div><br>
</div><div>----</div><div>Ursachen:</div><div><br></div><div>da diese firmware(s) weder 1. die vorhandene bandbreite irgendwie unter den usern aufteilen, <br>
2. noch OLSR pakete<br>noch 3. DNS requests bevorzugen <br>(gäbe noch weitere sinnvolle QOS rules (wie tcp acks bevorzugen, u.s.w)<br></div><div><br></div><div>zerlegt sich unter last das "netz" schnellmal,..</div>
<div><br></div><div>denn:</div><div><br></div><div>1. erlaubt es den torrents überdurchschnittlich viel bandbreite zu belegen,.. (d.h. andere z.b. surfende user sind schonmal etwas benachteiligt, aber es wäre vmtl noch recht ok oder zumindest benutzbar)<br>
<br>2. führt dann (weil olsr pakete genauso oft wie torrent pakete weggeworfen werden) zu schwankenden (und grundsätzlich niedrigeren) lq werten als bei keinem traffic.<br>dies führt dann potentiell laufend zu routing flaps, die es für surfende user schon ziemlich fad machen können, weil dabei mitunter (alle paar sekunden) etliche sekunden (gefühlt evt. permanent) einfach garnix "geht",.. <br>
<br>(wirklich garnix wenn der lq (des einzigen brauchbaren links) unter 0.1 gedrückt wird (-;)</div><div><br></div><div>übrigens: wäre das (durch torrents ausgelöste 'überlastungs') problem nit am brenner (der selber nen tunnel direkt zum uplink hat) und an dem viele user hängen die selber "nur" den brenner sehen, und somit wenig flap alterniven haben, wären die konsequenzen noch viel katastrophaler,..</div>
<div><br>3. führt dazu das dns udp pakete gleich wie die des torrents behandelt (und bei vollaufen der txqueue (auf jedem backfire node am weg) eben weggeworfen werden) <br>da dns clients/forwarder idr den unterschied zwischen "domain existiert wirklich nicht", und "dns server antwortet nicht" nicht sonderlich gut 'kennen'/'kapieren' <br>
führt das dazu dass webseiten/etc. dann (bis der lokale dns (not found) cache eintrag wieder verworfen wird) überhaupt nicht mehr "aufgehen",..#3
</div><div><br></div><div>ok genug der (mit QOS vermeidbaren) ursachen für "internet geht nix mehr"<br><br></div><div>(es gäb noch die eh schon in anderen mails gründlich angesprochenen conntrack overflows (vergleichsweise trivial vermeidbar), und auch airtime/noise auf lq rückkopplungen mit sleben abr idr deutlich schwächer ausgeprägten konsequenzen wie in 2.,...)</div>
<div><br>----<br>Lösungen:</div><div><div><br>leider ist es eben bei "neuen" geräten (mit ath9k (oder auch ath5k)) nicht mehr so "trivial" QOS zu machen als auf den alten broadcoms (linksys, etc.),.. #1 (sonst wärs ja wohl acuh schon längst gemacht)</div>
</div><div>(und (hauptsächlich deswegen) empfehle ich persönlich eben keine neuen geräte bzw. die firmwares dafür,.. #0)</div><div><br></div><div>allerdings ist es eigentlich auch bei verwendung von z.b. ath9k #2 moeglich (z.b. mit tc oder iptables) die pakete vorzukategorisieren, so dass der treiber in den eigenen queues die dann entsprechend behandelt, <br>
<br></div><div>eigentlich wollte ich mich dem themas schon lange selber annehmen, aber mir fehlt immer noch die zeit dafür,..<br>(aber evt. lasst sich da nächstes jahr was machen *g)</div><div><br></div><div>und/aber zumindest NOTRACK zwischen olsr interfaces sollte in den backfire vienna firmwares mal rasch eingebaut werden!</div>
<div><br></div><div>lg Markus</div><div><br></div><div>#0 obwohl auch meiner ansicht nach, die neuen geräte (bzw. jedfalls deren hardware und in vielen punkten auch die treiber) unumwunden besser/preiswärter/etc. als die alten sind,.. <br>
<br></div><div>d.h. auf privaten strecken (mit nur meinem eigenen traffic *G) würd ich sie empfehlen/selber verwenden, aber für meshtauglich halte ich sie halt nicht,.. (da ist lahme und auch taube hardware mit zuverlässigen funktionierendem forwarding mit QOS, imho noch immer die bessere wahl)<br>
<br></div><div>#1 da jegliche auf backpressure angewiesene QOS setups (idr) nicht funktionieren, weil diese wifi treiber keien (komplette) backpressure "aufbauen")<br><br>#2 dieser hat intern im gegensatz zu alten/simplen wifi treibern mit kurzen fifos) eigene lange queues und kategorisierungs/priorisierungs rules für traffic</div>
<div><br></div><div>#3 dagen hiilft eintragen von mehreren dns server zwar ein bißchen, (und dns im mesh über tcp statt udp abzuwicklen ein bißchen mehr,..)</div><div>aber am sinnvollsten ist es auf jeder node QOS zu haben das dns requests schützt/bevorzugt, und nur im äussersten 'notfall' wegwirft,..</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">manche haben auch sogut wie keine verbindung mehr<br></blockquote><div>leider nicht verwunderlich,.. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
auf der nortwest brenner<br>
<br>
*GRUML<br>
<span><font color="#888888"><br></font></span></blockquote></div>