<p>also ich hab nun heut den olsr traffic zwischen tunnelserver und gallbrun eingehend analysiert,..</p><p>es handelt sich um ca 30/35kbit dauerlast in up und downstream bzw somit 20GB Gesamt/Monat (der tunnel nach gallbrunn ist da aber keinerlei ausnahme)</p>
<p>A 4% davon wird von den routern in gallbrunn selber erzeugt</p><p>B 4% macht der tunnelserver</p><p>C 49% stammt aus dem funkfeuer netz (exkl. gallbrunn) und wird vom tunnelserver nach gallbrun weitergeleitet</p><p>D 43% macht der retourgesandte traffic von gallbrunn zum tunnelsver von C</p>
<p>an A kann erich mittels olsr timings und vorallem olsr upgrades in gallbrunn etwas ändern,..</p><p>an B könnte man imho nur noch kleinwenig was ändern, allerdings sind die timings vom tunnelserver eh schon niedriger als üblich, ...</p>
<p>an C kann man nur recht schwer schnell was ändern, </p><p>1. alle alten olsrs aus dem netz verschiwnden (allerdings haben wir noch keine neuen olsr versionen die erwiesenermassen genauso verlässlich funktionieren),<br>
2. auf geplante schon enstehende oslr entwicklungen warten,. (CSN, stabilere metriken, adaptive timings, usw.)<br><br>erwartbar durch 1. wäre wohl eine reduktion auf die hälfte,.. durch 2. dann um evt. 90%</p><p>diese Verbesserungen würden indirekt dann auch 1:1 den traffic von D senken,.. (#)</p>
<p>an D kann man mit brandneuen oslrs etwas ändern, (d.h. diesen traffic komplett eleminieren) allerdings funktinoeren die oslr-versionen die das können erwiesenermassen noch nicht stabil</p><p>lg Markus</p><p># zusätzlich könnte man für ausgewählte tunnel den traffic noch weiter senken in den man nur olsr-messages mit hoher ttl am tunnelserver weiterleitet (allerdings funktionert das auch nur dann wirklich gut wenn (fast) keine fff <= 1.6.28 im netz vorhanden sind) (die Verbesserungen in C.2 wird sowas aber dann auch wieder obsolet machen)</p>