[Freifunk-Bonn] Node-Crashes, Watchdog / Ath9k-Issues: Aktueller Stand und Ausblick
Jan Lühr
ff at stephan.homeunix.net
Di Mär 5 14:54:50 CET 2013
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
Mehr Informationen über die Mailingliste Freifunk-Bonn