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

Ruben Kelevra cyrond at gmail.com
Mi Mär 6 02:56:31 CET 2013


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



Mehr Informationen über die Mailingliste Freifunk-Bonn