[Dump] parallelle meshes

[Markus Kittenberger]

das ich ja auch ähnliches vorhab,.. (wir dann also schon bei 3 routing
daemons pro Router wären)

(allerdings k.a. ob ich zuerst einen olsr-fork mit paar intressanten mods #
mach, und dann erst mit parallel setup anfang oder umgekehrt)

und die ressourcen eines routers irgendwannmal zu neige gehen,..

wir wärs mit folgendem (auch als vertrauensfördendes für argwöhnihsche, oder
kompromissvorschlag fürn aaron)

die einzelnen parallel-netze kriegen timeslots,..

d.h. evt anfangs nur nachts, jedenfalls halt nicht primetime,..

und halt nie mehr als 2 daemons gleichzeitig

whatever,..

könnt vertrauenfördernd sein, oder das gegnteil bewirken, doer aber auch im
endeffekt uns auch ärger machen,..

denn wer stellt dann die timeslots ein (ich würde das eher nicht dem
node-owner (alleinig) in die hand geben wollen)

lg MArkus

ne andere frage, wie hast du vor babel im ipkg zu konfigurieren

auf allen interfaces, oder nur auf wan/funk, oder auf denen wo auch olsr
läuft,..

#  zurzeit angedachte mods (und mit kaum rücksicht auf RFC kompatibilität
(vorallem punkt D))

A: lq-metrik mit sehr wenigen werten,
und adaptiver validity time  -> nur sehr wenige metrikänderungen und auch
sehr wenige tcs
-> wenig traffic, und darum kein fisheye mehr nötig
B: evt. latenzmessungen der links, evt. unicast packetloss messungen
C: evt. non-wlandriver based linkspeed messungen (keineswegs genau)
und das eher nur bei links mit wenig packetloss
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
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,..
d.h. ziel ist jedenfalls deutlich gleichzeitiger als jetzt
vermutlich werd ichs aber doch nicht probieren das ganze mesh zu
synchronisieren (-;
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)
E: sofortiges weitersenden von katastrophen-tcs (d.h. kein zamsammeln von
messages auf ein grosses paket) und tcs mit niedriger ttv
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,..
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,..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/dump/attachments/20081224/91ff39fd/attachment.html>