<br><br><div class="gmail_quote">2008/12/21 Adrian D <span dir="ltr"><<a href="mailto:atrox@quintessenz.org">atrox@quintessenz.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
wir haben das selbe problem wie mit einem metrik-update bei olsr: wir<br>
brauchen einen testmöglichkeit bzw einen update-pfad für das netz.<br>
adhoc fallen mir zwei varianten ein: ein anderer ip range </blockquote><div>für die evaluierungphase wür d ich sagen parallellauf, </div><div>.</div><div>und ja sobald man sich für nen umstieg entschieden hat (egal ob metrikwechsel oder routingdaemon oder beides), muss man halt für das bisher z.b. in anderer ip range operienden testnetz aufs gesamte mesh vergrössern und ihm wenn noch nötig auch public ips geben das dann jeder auf dieses umsteigen kann, (das alte aber ncoh ne weile weiterläuft,..)</div>
<div>.</div><div>aber vorerst sind das nur mal die ersten evaluierungsschirtte, umstieg steht ncoh nciht im raum</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
oder ein<br>
anderes vlan über funk. </blockquote><div>vlans funktioneren nicht verlässlich, hab noch nie wrklich funktionierende vlans zwischen ner fonera und nem linksys zamgebracht</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
beides hat den nachteil es irgendwann mal eine<br>
big-bang-umstellung geben muss - aber vielleicht fällt uns noch was<br>
besseres ein? eines, wo wir routen über die jeweils andere metrik</blockquote><div>alles ist machbar, aber alles muss auch wer machen,.. (-; <br>.<br></div><div>verschiedene routing-daemons können untereinander routen austauschen, ein routingdamoen kann auch könnt auchg mehrere metriken parallel fahren,.. usw.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
automatisch integrieren können? hmm..<br>
allzu lange werden wir uns davor nicht mehr drücken können.<br>
<br>
<br>
ich war leider nicht bei dem babel-vortrag dabei, hab jetzt nur die<br>
folien gesehen und muss sagen: super dass man sich wichtiger nachteile<br>
des olsr angenommen hat (zb synchronizität bei route veränderungen).<br>
aber ein zentraler nachteil bleibt: es verwendet ebenfalls die<br>
ETX-metrik mit den zwei gravierendsten nachteilen: </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
*) es bewertet einen hop mit 50% packetloss (ETX=2) als besser, als zwei<br>
hops mit jeweils nur 1% packetloss (ETX 1.01+1.01=2.02)</blockquote><div>das mag desweilen auch gut sein, würden alle ihre persönlich beste routen kriegen die dann länger und theoretisch schneller wären, ist das schnell mal insgesamt schlechter, weil es global weitaus mehr airtime braucht</div>
<div>.</div><div>aber klar ich liebe etx auch nicht</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
*) wird ein link tatsächlich belastet, konkurrieren datenpakete mit</blockquote><div>indirekt über die airtime ja (da stören aber eher benachbarte links mehr als der eigene), direkt nur wenn keine entsprechende traffic control (wie sie auf auf jedem freifunk-router existiert) (aka. QOS) konfiguriert ist,..</div>
<div>.</div><div>aber auch das ist ein metrik problem,.</div><div>.</div><div>olsr kann nur nebenbei schlecht mit diesen "schnellen" metrikänderungen umgehen,.. und auch schlecht mit anderen metriken welche z.b. auch auf bandbreite rücksicht nehmen und dadurch auch mutmasslich mehr metrik schwankungen haben werden,..</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
hellopaketen was den ETX wert ansteigen läßt, und zu route-switching auf<br>
 schlechtere routen führen kann. </blockquote><div>schlechter ist realtiv, die andere route ist ja scheints bei dem beispiel ja eh überlastet, problematisch ist eher das dies gern zum schwingen anfängt,..</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
zumindest kommt es bei babel beim<br>
routswitching nicht zu einstweiligen schleifen und damit zu aussetzern.</blockquote><div>mal sehen,.. (-; </div><div></div><div>das sind im grund metrikprobleme, keineswegs unwichtig, aber wechselbar (metrikwechsel sind natürlich auch nicht leichter als routingdaemonwechsel)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br></blockquote></div>