[WLANware] Wie weit skaliert OLSR

[Sven-Ola Tuecke]

Hallo,

den Last=n*log(n) Patch gibts ab olsrd-0.5.1. Ein Netz-Zusammenbruch wg. 
Rechenlast passiert immer auf Raten. Etwa so:

- Zuerst Kisten mit wenig CPU-Freq aus (z.B. gaaanz
  langsame Reaktion auf SSH oder Web-Abfragen). Gerne hier:
  alte WRT54G mit 125 Mhz MIPS.

- Dann kommen die Geraete mit Themperaturprobs dran, z.B.
  die sowieso schon zu warm sind und/oder keine Kuehlkoerper
  haben oder eh' zu den 10% Ausschuss gehoeren. Einfach weg.

- Zuviel CPU == Paketloss z.B. auf Ethernet obwohl schon die
   UDP-Buffer hoch und die Polltime 'runtergedreht ist.

- Dann noch wild pendelnde ETX-Werte auf sonst zuverlaessigen
   Stecken, was ordentlich Routen-Flaps ausloest.

All diese Effekte mit steigender Tendenz, bis eine Wolke sich in mehrere 
Teile aufsplittet und wieder sporadisch zusammenfindet. Wegen 
In-Band-Debugging (wir haben ja i.d.R keine zweite Connection) kann man 
sowas auch nur schwierig beobachten. Aber so etwa lief es das letzte mal 
hier in Berlin ab (schon ueber ein Jahr her).

Im Moment ist jedenfalls alles prima. Meine langsamste Kiste (mein 
WAP54Gv1.0 zeigt mit "top" zwischen 15 und 30% fuer den 
olsrd-mit-spf-refactoring, er hat 3 Nachbarn). Das ist ganz prima so. 
Weitere Angaben:

root at sven-ola-wap:~# ip r | wc -l
    418
root at sven-ola-wap:~# cat /proc/cpuinfo
system type             : Broadcom BCM947XX
processor               : 0
cpu model               : BCM4710 V0.0
BogoMIPS                : 82.94
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available
root at sven-ola-wap:~# nvram show | grep freq
size: 6144 bytes (26624 left)
clkfreq=125

// Sven-Ola

"Marco Tedaldi" <marco.tedaldi at gmx.ch> schrieb im Newsbeitrag 
news:46B052BB.60503 at gmx.ch...
Daniel Nitzpon schrieb:
> hi!
> seit neuestem wächst die olsr-load nur noch mit O(n*log(n)). (vorher
> O(n^2)).

Hm, das tönt schonmal ermutigend, Ab welcher olsrd/ff-version ist das
der Fall?

> wir haben hier in leipzig etwas über 600 nodes in einer wolke (mit vpn
> und so), ohne dass die cpu-load der wrts unerträglich würde (bei mir
> 0.6-0.7 im durchschnitt). die cpu-load ist glaube ich beim einzelsystem
> meist die kritischere größe als der ram.

Ok. Was passiert, wenn der Load zu gross wird? Ein Rechner kann
einwandfrei mit einem Load über 1 funktionieren (auch Load 5 muss nicht
zwingend ein Problem darstellen). Wieviel % der cpu-zeit verbrät denn
der olsrd unter welchen Umständen? Wenn der LOAD natürlich
ausschliesslich durch den olsrd verursacht wird, dann deutet 1.0 in
diesem Fall schon auf Probleme hin.
Bricht die Routenberechung zusammen, wenn die anzahl der router eine
bestimmte Grenze überschreitet? Wird das Netz instabil? Wird die
Anpassung an Änderungen einfach langsamer?
Konkret: leidet einfach die Performance, oder gibts nen Zusammenbruch?

> für das gesamtnetz nicht zu vernachlässigen ist auch der traffic, den
> olsr verursacht und der sich an dicht befunkten stellen durchaus auf
> 30-40 kb/s beläuft (aber bei eingeschaltetem fischeye dann deutlich
> weniger als linear mit der nodedichte wächst).

Hier ist der Traffic, wenn sonst kein Datenverkehr herrscht bei gut 250
Router im Netz bei ca. 2kiB/s.

> die 1000er-grenze könnte gefühlsmässig ein passender wert sein, richtig
> testen kannst du das wohl nur mit 1000 virtuellen (oder natürlich realen
> (-: ) maschinen. ausrechnen kann man das natürlich auch irgendwie, wenn
> man sich bei den parametern nicht verschätzt...
>
Ok... die 1000 scheinen im allgemeinen Konsens der Wert zu sein, wenn
auch den WRTs die Puste CPU-mässig ausgeht.
Könnte man sowas mit dem olsr-switch testen? Wenn ja: wie?

> wenn du bedenken wegen der skalierbarkeit hast: hast du dir mal batman
> angeschaut? das ist eigentlich dafür gemacht, besser zu skalieren. ist
> aber noch recht neu.
>
Angeschaut ist zuviel gesagt. Ich les auf der Mailingliste mit. Ist
sicher ein interessanter Ansatz, den ich gerne mal testen werde. Aber
für den Produktiveinsatz m.E. definitiv noch nicht bereit.

Grüsse

Marco

> Marco Tedaldi schrieb:
>> Moin moin allerseits
>>
>> Jup, ich bin recht neu hier. Ich bin aktiv bei openwireless, in St.
>> Gallen (http://sg.openwireless.ch), also ein Schweizer :-)
>>
>> Unser Netz wächst rasant. Es ist ein sehr unstrukturiertes Netz, dass
>> sich über die ganze Stadt erstreckt (zumindest über Teile davon). Alles
>> in einem IP-Bereich.
>> Aktuell sind so zwischen 250-300 Geräte gleichzeitig in Betrieb im
>> Kernnetz (es gibt noch ein paar Inseln, mit eigener Internet-Verbindung
>> aber keiner Verbindung zum Hauptnetz).
>> Da ja jeder Router das gesamte Netz kennt, wird da irgendwo ne Grenze
>> sein, ab wann entweder irgen eine Tabelle überläuft, das RAM voll ist
>> oder der Prozessor nicht mehr nachkommt. Gerüchte besagen, dass diese
>> Grenze bei ca. 1000 Geräten liegt.
>>
>> Kann ich dies irgendwie testen (Ohne 1000 geräte zu kaufen,
>> konfigurieren udn aufzustellen)?
>> Welche Lösungen/Lösungsansätze gibt es, das Problem zu umgehen?
>>
>>
>> Grüsse
>>
>> Marco
>>
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
>
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung 
> unter http://freifunk.net/mailinglisten
>

_______________________________________________
WLANware mailing list
WLANware at freifunk.net
Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware

Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung 
unter http://freifunk.net/mailinglisten