[Freifunk-Bonn] Node-Crashes, Watchdog / Ath9k-Issues: Aktueller Stand und Ausblick

Mi Mär 6 09:45:17 CET 2013

Hallo,

Subgroup-Discovery wäre Schritt 3.4 oder noch später ;-) - da muss erst der Watchdog mehr Daten liefern.

Alles Gute
Jan

Am 06.03.2013 um 02:56 schrieb Ruben Kelevra:

> Was haben die beiden Nodes gemein die so viele Ausfälle zu Verbuchen
> haben, lässt sich da eine Aussage über die Umstände ableiten?
> 
> Viel / Wenig Traffic?
> Viele Nachbarn?
> Viele Clients?
> Störquellen?
> 
> 
> LG Ruben
> 
> 
> Am 5. März 2013 17:33 schrieb Christof Spies <christof.spies at seips.net>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Nur um das Problem mal zu Quantifizieren:
>> Wir sprechen über die letzten 20 Tage.
>> In der Zeit haben 11 von 32 Nodes zusammen 60 Watchdog Events gemeldet.
>> 4 nodes 1-2 events
>> 5 nodes 4-8 events
>> 2 nodes 11-13 events
>> 
>> Wohl gemerkt in 20 Tagen.
>> C
>> 
>> 
>> Am 05.03.2013 14:54, schrieb Jan Lühr:
>>> Hallo folks,
>>> 
>>> 1. Einleitung seid einiger Zeit beobachten wir die Vorgänge (insb.
>>> Watchdog-Bisse) in unserem Freifunk-Netz. Mittlerweile sind uns 60
>>> Ergeinisse bekannt, in denen der Watchdog ausgelöst hat
>>> (http://register.kbu.freifunk.net/watchdog_bites) - die Hoffnung
>>> auf eine schnelle Lösung unserer WLAN-Problem ist dabei relativ
>>> gering.
>>> 
>>> 2. Aktueller Stand Konsens unter vielen Freifunker ist Zeit, dass
>>> die Fehlermeldung ein Hinweis für "irgendein"-Problem bei der
>>> Kommunikation zwischen wlan-Chip und ath9k-Treiber ist. Leider gibt
>>> es (und gab es) viele Situationen, in denen ein solches Problem
>>> auftreten kann. Entsprechend vielfältig sind möglich Workarounds
>>> (HT20 / HT40, WMM ja / nein, DE-/ US-Locales, Short-GI ja/ nein,
>>> no-scan ja / nein), die in vielen Fällen für einzelne Bugs gedacht
>>> waren / sind. Inzwischen gibt es zwar einen Patch im ath9k-Treiber,
>>> der jedoch nicht in allen Fällen funktioniert (Kommentar 43,
>>> https://dev.openwrt.org/ticket/11862). Darüber hinaus wurde in
>>> Oldenburg ein wlan-Ausfall beobachtet, bei dem der Ringbuffer
>>> sauber aussieht (http://pastie.org/6371359), d.h. unser Watchdog
>>> keinen Reset ausgelöst hätte.
>>> 
>>> 3. Ausblick / TODOs Imho macht ein weiteres vorgehen wie folgt
>>> sinn:
>>> 
>>> 3.1 Statistik. - Wir können nun anfangen, die Crashes statisch
>>> aufzuarbeiten und darzustellen. Wir haben inzwischen einige
>>> Rohdaten gesammelt die erste Beobachtungen zulassen. (Einige Nodes
>>> crash'en häufiger, andere kaum oder gar nicht). Ziel der
>>> Darstellung ist es imho: -> Nodes identifizieren, die häufig
>>> crash'en, so wie deren Crash-Verhalten (Häufigkeit / Uhrzeit). ->
>>> Pro Node, die Crash-Häufigkeit über die Zeit darstellen. (Welche
>>> Auswirkung hat ein Firmware-Upgrade?). Auch im Vergleich mit
>>> anderen Nodes, bei denen ebenfalls ein Firmware-Upgrade erfolgt
>>> ist. Genial wäre es, wenn wir am Ende sagen können, dass ein
>>> Firmware-Update unter eine Einstellung eine statistisch
>>> signifikante Besserung bringt.
>>> 
>>> Wer von Euch hat Lust sich darum zu kümmern? Genial wären
>>> Vorkenntnisse im Bereich Statistik (Konfidenzintervalle, etc. - bei
>>> unserer Physiker-Quote gibt's doch gute Leute ...) Am einfachsten
>>> wäre es wohl, PNGs mit Gnuplot oder R zu erzeugen und in das
>>> Node-Register einzubinden.
>>> 
>>> 3.2. Kriterien Wir müssen weitere Kriterien / Heuristiken finden,
>>> die ermitteln, ob das wlan an einem Node ausgefallen ist und ein
>>> Watchdog-Reset erfolgen soll. Steigen bspw. dieTX-Error Counter an
>>> oder fällt TX unter den Wert, den batman-adv minimal erzeugt, so
>>> können dies auch Hinweis für einen Crash sein. (@Rampone, @Bjo:
>>> Bitte haltet eure Augen auf). Wir können auch darüber nachdenken,
>>> alle Nodes in festen Abständen zu resetten, um nicht erkannt
>>> Vorfälle zu beheben. Eine Zusammenhang mit dem Datendurchsatz (z.B.
>>> starker Anstieg nach einem Reset) wäre ein Indiz für nicht erkannte
>>> crashes.
>>> 
>>> 
>>> 3.3. Weitere Watchdog-Daten Ich werde mich für das nächste
>>> Firmware-Release darum kümmern, den Watchdog auszubauen, um noch
>>> weitere Informationen (insb. ath9k-Debugging-Daten) an die Server
>>> zu übermitteln. Somit sollten wir ein detailliertes Bild einige
>>> Crashes haben (will noch jemand mitmachen?).
>>> 
>>> So, das war's dann - Details können wir am Donnerstag diskutieren.
>>> 
>>> Alles Gute Jan
>>> 
>> 
>> 
>> - --
>> seips.net UG (haftungsbeschränkt)
>> Hadwigastraße 39
>> 51069 Köln
>> 
>> Tel: +49 221 677 883 50
>> Fax: +49 221 677 883 51
>> Email: christof.spies at seips.net
>> Web: http://www.seips.net
>> 
>> Registergericht: Köln
>> Registernummer: HRB 69303
>> Geschäftsführer: Christof Spies
>> USt-IdNr: DE271408527
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.17 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQEcBAEBAgAGBQJRNh5LAAoJEKRl9G3mpUgo9U8IAKq2vGDpOzB18wiEjSB21KT2
>> flvmpbGXgPYWq96mVz/UJHCNVwoul3JJjUTieGFcBV98e8RTLeeF4nxAKTB/YiVx
>> zrZXuzRlajlvK2LxxdPov/or6n3D6kM5ksScElij8CxdLJX2UAwpsrqkYdR8r0CW
>> BX9WXYyG9QTeV7O8WKCG0vj/NUugLndxLeavtSbnkrC9PZQA2+1l0aN8IPi9xNWH
>> Mql5fKx/E4mgqlhMXOVI8JRtM+HKx/Sm70b6+FHbNON3riMT1MLHoiHZJ40ABB5l
>> HTnNwKT1xdAwjqRaKFx4sjOu9CkmZAcFvdlqYMLLgpS7FZ0xDFCxlkwLCJsReeA=
>> =wMmZ
>> -----END PGP SIGNATURE-----
>> --
>> _______________________________________________
>> Freifunk-Bonn mailing list
>> Freifunk-Bonn at lists.bonn.freifunk.net
>> http://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn
> -- 
> _______________________________________________
> Freifunk-Bonn mailing list
> Freifunk-Bonn at lists.bonn.freifunk.net
> http://lists.kbu.freifunk.net/cgi-bin/mailman/listinfo/freifunk-bonn