[PATCH 0/2] Enable the batman-adv Gateway selection

[Christian Dresel]

Hallo

erste Beobachtungen (die letzten halbe Stunde, also noch nicht wirklich 
repräsentativ) meines Teilausgelasteten (endlich mal über 100 Clients) 
Server zeigen mir ein ganz anderes Problem als die Bandbreite.

Wie Tim erklärt hat sind die Paketzahlen extrem hoch, owbwohl ich gerade 
mal im Schnitt 25-30MBit /Sec über das Netzwerkinterface Schaufel (davon 
nur wenige (3-5)MBit durch den Mullvad Tunnel wo geht eigentlich der 
Rest hin? Haben wir doch etwas mehr internen Traffic als ich bisher 
dachte oder ist das einfach die riesen Broadcastmenge?) bricht der Speed 
richtig ein. Die Auslastung des Server ist aktuell grenzwertig (loadavg 
von ca. 1 und %CPU Last auf den fastd Prozessen zwischen 50-80%, si bei 
10-20), ansonsten lässt er sich aber noch sehr flüssig bedienen und 
reagiert auch zügig auf alle möglichen Anfragen (ping, apache, mysql usw.).
Wichtig auch, auf dem Server (mit wget direkt übers Netzwerkinterface) 
konnte ich früher ohne Belastung mit etwa 400MBit Dateien runterladen 
(so bei 50Mbyte/sec war immer Schluss), jetzt wo er voller ist komm ich 
auf langweilige knappe 100MBit (obwohl für Freifunk gerade mal 30 MBit 
belegt sind)

Speedtests bei leeren Server:
- 18Mbit Down 8Mbit Upo gemessen hier in Fürth über meinen 50MBIT VDSL 
Anschluss, hier war der Flaschenhals wohl der wr841nd Router der einfach 
nicht mehr packt. Die Grenze wurde zu verschiedenen Zeiten immer wieder 
erreicht. Es gehen also problemlos 18Mbit über den Mullvad-VPN Tunnel 
(und vermutlich mehr da, wie gesagt, der wr841 wohl der Flaschenhals 
ist). Wenn ich in Nürnberg nicht mehr gebraucht werde und sich der 
Server wieder mit 3-5 Clients langweilg wäre wohl ein Speedtest über 
einen größeren Router mal imnteressant.

Speedtest heute bei relativ vollen Server aber nicht wirklich 
ausgelasteten Interface (als ich den Test gestartet hab, lief über das 
Mullvad VPN gerade mal ~1-2Mbit, ging dann durch meinen Test natürlich 
hoch):

- 3MBit Down 6Mbit Upload (warum der Upload höher ist, ist mir 
schleierhaft), die Leitung sollte eigentlich noch deutlich mehr 
hergeben, dabei gingen kaum 10MBit über den Mullvad-VPN Tunnel

Ich glaube(!) daher aktuell nicht, das der Mullvad Tunnel der 
begrenzende Faktor ist. Vom aktuellen "Surfspeedgefühl" ist allerdings 
noch alles super flüssig, Seiten laden sofort und schnell.

Hier stellst sich dann die Frage wie ich die GW Selection hier sinnvoll 
einstellen sollte wenn wir sie scharf schalten. Ich glaube es macht hier 
eher Sinn, die Anzahl der DHCP Clients zu begrenzen, wenn ich das 
hochrechne und abschätze ich könnte ich bei etwa 150-200 Clients zu 
machen, wenn Not am Man... äh Server ist vielleicht 255 mehr wird dann 
aber keinen Sinn mehr machen (ok muss man mal ausprobieren, vielleicht 
täusch ich mich auch), für genauere Zahlen müsste ich das einfach mal 
testen.
Einzigen Sinn denn ich dann noch in der GW Selection sehe liegt darin, 
dann ich den Traffic ganz schick begrenzen kann. Ich hab mal mit 
wondershaper rum gespielt dies hat mir die Bandbreite aber nicht 
sinnvoll begrenzt sondern nahezu komplett zu gemacht (hab 40000 / 40000 
kbit freigegegeben am Ende war bei 2-3 MBit dann Schluss, tlw. runter 
bis auf wenige kbit/sec) warum ist mir Schleierhaft, evtl. wieder die 
Paketmenge mit der das Programm nicht klar kommt?

Ich hab aktuell den "Luxus" das ich etwas mit teilausgelasteten Server 
herumprobieren kann und da sieht man solche Zahlen doch sehr gut.

mfg

Christian

Am 20.09.2015 um 11:33 schrieb Tom Green:
> Hi Tim,
> Hallo Zusammen,
>
> Wie wir gestern diskutiert haben, macht es für die B.A.T.M.A.N Gateway
> Selection auf dem Gateway Sinn, nur die  freie Bandbreite an die Router
> zu annoncieren,  und nicht die gesamte.
>
> Ich hab ein einfaches Skript geschrieben, dass diesen Zweck erfüllen sollte.
>
> Es liegt unter:
> https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen#B.A.T.M.A.N_Gateway_Selection
>
> Gruß
> Torben
>
>
>
> On 14.09.2015 22:42, Tim Niemeyer wrote:
>> Hi Tom
>>
>> Am Montag, den 14.09.2015, 22:38 +0200 schrieb Tom Green:
>>> Wechseln dann alle Clients das GW mit, oder nur die neuen?
>> Nur die neuen. Aber bitte schau mal hier, da ist der Mechanismus prima
>> erklärt:
>> http://www.open-mesh.org/projects/batman-adv/wiki/Gateways
>>
>> Hier sind die verfügbaren Parameter dokumentiert:
>> http://downloads.open-mesh.org/batman/manpages/batctl.8.html
>>
>> Um den Algorithmus dahinter zu sehen / zu verstehen, muss man leider in
>> den Code gucken:
>> http://git.open-mesh.org/batman-adv.git/blob/f5e3096f8f7e4135a651a2b0cb78ae1ba1dc805f:/gateway_client.c#l144
>>
>> Tim
>>
>>
>>> Wenn es alle sind, stell mir das so vor, als ob dann ganze Herrscharen
>>> das GW wechseln, auslasten, um dann als Schwarm ein oder zwei Minuten
>>> über das nächste GW herzufallen (und dabei die externe IP zu wechseln,
>>> was mitten im Youtube Video vielleicht nicht so gut kommt).
>>>
>>>
>>> On 14.09.2015 21:58, Tim Niemeyer wrote:
>>>> This Patchset enables the gateway selection and adds a cron to reset the
>>>> selection every one minute. I didn't find a better way to tell batman to
>>>> look for newer and better gateways.
>>>>
>>>> I tried different gateway selection classes, only class 1 allows us to
>>>> take care of the selection via the announced bandwidth. Unfortunately the
>>>> class 1 stick with the selection until the gateway disappears. Even if a
>>>> much better gateway is announced the node will stay with that gateway. To encounter this behaviour, the cron disables the client mode for one second.
>>>> This will tell batman to make a new evaluation.
>>>>
>>>> Attention: By applying this patches only Hoods with enabled gateway selection
>>>> can serve DHCP to Client.
>>>>
>>>>
>>>> Tim Niemeyer (2):
>>>>    batman-adv: enabled client gateway mode
>>>>    cron: disable every 1min the gw selection for 1s
>>>>
>>>>   bsp/default/root_file_system/etc/config/batman-adv | 4 ++--
>>>>   bsp/default/root_file_system/etc/crontabs/root     | 1 +
>>>>   2 files changed, 3 insertions(+), 2 deletions(-)
>>>>