<p>das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing daemons pro Router wären)<br></p><p>(allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods # mach, und dann erst mit parallel setup anfang oder umgekehrt)</p>
<p>und die ressourcen eines routers irgendwannmal zu neige gehen,..</p><p>wir wärs mit folgendem (auch als vertrauensfördendes für argwöhnihsche, oder kompromissvorschlag fürn aaron)</p><p>die einzelnen parallel-netze kriegen timeslots,..</p>
<p>d.h. evt anfangs nur nachts, jedenfalls halt nicht primetime,..</p><p>und halt nie mehr als 2 daemons gleichzeitig</p><p>whatever,..</p><p>könnt vertrauenfördernd sein, oder das gegnteil bewirken, doer aber auch im endeffekt uns auch ärger machen,..</p>
<p>denn wer stellt dann die timeslots ein (ich würde das eher nicht dem node-owner (alleinig) in die hand geben wollen)</p><p>lg MArkus</p><p>ne andere frage, wie hast du vor babel im ipkg zu konfigurieren</p><p>auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr läuft,..</p>
<p>#  zurzeit angedachte mods (und mit kaum rücksicht auf RFC kompatibilität (vorallem punkt D))</p><p>A: lq-metrik mit sehr wenigen werten,<br>und adaptiver validity time  -> nur sehr wenige metrikänderungen und auch sehr wenige tcs<br>
-> wenig traffic, und darum kein fisheye mehr nötig<br>B: evt. latenzmessungen der links, evt. unicast packetloss messungen<br>C: evt. non-wlandriver based linkspeed messungen (keineswegs genau)<br>und das eher nur bei links mit wenig packetloss<br>
denn ich will nicht das ein link mit nennswert (d.h unicat packetloss erwartbar) packetloss nen besserer metrik kriegen kann, als ein langsamer ohn packetloss<br>D: gewisse zeitliche synchonisierung (d.h. neue metrikwerte (wenn sie nicht exrteme verschlechterungen sind)) werden announct, aber erst z.b. 10 sekunden später (abhängig von meshgrösse und der dringlichkeit)  (überall möglichst gleichzeitg) umgesetzt wird,..<br>
d.h. ziel ist jedenfalls deutlich gleichzeitiger als jetzt <br>vermutlich werd ichs aber doch nicht probieren das ganze mesh zu synchronisieren (-;<br>sondern einfach in den oslr paketen mit nem zusätzlichen timetovalidity (ttv) feld, immer abziehen wie lange das paket warten musste (und auch die bekannte durchschnitts-latenz des incoming links) (da ich fisheye eh auch weglassen will, ersetzte ich evt ttl durch ttv, allerdings bezweifle ich ob ich mit 8bit auskomm)<br>
E: sofortiges weitersenden von katastrophen-tcs (d.h. kein zamsammeln von messages auf ein grosses paket) und tcs mit niedriger ttv<br>d.h. wenn einer seiner links plötzlich irre schlecht wird schickt der olsr tcs mit niedriger ttv, und erwartet das schnellstmöglich jeder davon erfährt,..<br>
gleichzeitg werd ich irgendwas einbauen müssen, dass evt. auf jeden knoten ein ratelimit (pro orinigator) gibt wieoft er solche tcs schicken darf und diese auch wirkich sofort weitergeleitet werden,..<br></p>