From (spam-protected) Mon Jan 5 00:48:49 2009 From: (spam-protected) (Markus Kittenberger) Date: Mon, 5 Jan 2009 00:48:49 +0100 Subject: [Dump] Test: wieviel cpu load denn wirklich bei monitor mode Message-ID: <4095b6c00901041548t207a5669p46c0806057b50704@mail.gmail.com> fyi Da ja für metriken, oder zeitsynchronisation mithilfe von beacon timestamps, whatever.. , wlan monitor mode als input ja nit unintressant wäre und ich aber auch die "wireless legend" kannte das monitor-mode "urviel" cpulast macht,.. . hab ich heut mal austesten wollen wieviel cpu das denn wirklich kostet,.. . und die ergebnisse sind überraschend (unmessbar) niedrig, ... . also das testsetup: ein buffalo (heunord) mit freifunkfirmware, mit ner kleinen outdoor-antenne, d.h auch ein bißchen noise von der stadt und im grunde nur ein nachbar mit 5,5mbit wlanrate (heuklein) . da ohne generierten testtraffic bei dump des monitor devices nur ein paar beacons und olsr pakete auftauchten (also keine messbare load zu erwarten war), kam zum erzeugen von ca. 500 packete/Sekunde an wlantraffic ein http stream vom heuklein zum heunord hinzu mit ca 2,5 mbit netto, untrig als testtraffic bezeichnet. . und zum verifizieren ob denn die angeblich freie cpu-time auch wirklich frei ist, hab ich wget -O /dev/null http://127.0.0.1/cgi-bin-dev-zero.bin gmacht (dessen throughput nachkontrollierterweise auch immer linear zur cpuload der dabei beteiligten prozesse war (httpd,cat und wget)) untrig als testload summiert angegeben . und nun die testergebnisse (cpu load von top -d 60) --- ohne wlan traffic von/zu heuklein: 95% testload (und mutmasslich 5% kernelzeugs) --- mit wlantraffic von heuklein zu heunord: 86% testload 5% wget (testtraffic) d.h 91% in summe d.h. 4% fehlten (zu den obigen 95%) diese 4% rechne ich mal dem kernel/wlanteriber zu, der ja den testtraffic ja auch verarbeiten musste,.. ---- mit wl monitor 1 86% testload 5% wget (testtraffic) also immer noch 91% in summe ---- und dann noch zusätzlich tcpdump -s 1800 -ni prism0 > /dev/null 82% testload 4.6% testtraffic 4.1% tcpdump in summe immer noch 90,7% --- machte ich hingegen ein tcpdump -ni prism0 udp > /dev/null, welches nur die paar wenigen olsr pakete dumpen sollte, hatte tcpdump nur 0.0% load (allerdings bei keinerlei egumpten paketen da der udp protokoll match mit prism0 als interface wohl nit funktioniert, ich also nun nicht weiss ob überhaupt pakete vom gecptured wurden...) (und die anderen prozesse hatten da in summer wiederum knapp 91%) --- mein schluss ist, das aktivieren und auch nutzen des prism0 monitor interfaces macht keinerlei (bzw extrem wenig) zusätzlicher (kernel-) load . lediglich das verarbeiten der vom prism0 gelesenen pakete (mit horst-artigem) wird wohl bei früheren derartigen versuchen die kolporierten extreme load erzeugt haben,.. tcpdump ist jedoch bei obigen versuch sogar effizienter als wget den testtraffic(samt beacons & co) nach dev/null zu befördern,.. lg Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From (spam-protected) Sun Jan 11 03:49:56 2009 From: (spam-protected) (Harald Geyer) Date: Sun, 11 Jan 2009 03:49:56 +0100 Subject: [Dump] Frisst der Linuxkernel Pakete? In-Reply-To: <4095b6c00901101427q65ed15edv8494413e90fb18f9@mail.gmail.com> References: <4095b6c00901082104i56946046x34c32ded000903c3@mail.gmail.com> <4095b6c00901091854s52c2a289ica4b0a393a222a92@mail.gmail.com> <4095b6c00901101201x3622985cnfe905a213ff8684c@mail.gmail.com> <4095b6c00901101235k7ed5abf4i5f1c25ca7d7c69a7@mail.gmail.com> <4095b6c00901101244i244eec3dubb29c3aecbe00310@mail.gmail.com> <4095b6c00901101427q65ed15edv8494413e90fb18f9@mail.gmail.com> Message-ID: [ CC and dump, vielleicht hat ja wer eine Idee oder findet das sonst spannend] Zur Erklärung für dump-Leser: Wir haben gerade das Problem, dass am devVserver (der mehrere IPs hat) Packete an eine bestimme seiner IPs (193.238.157.18) einfach verschwinden, wenn die Source IP des Pakets aus einer bestimmten range ist. > > Ja es ist schon sonderbar, vor allem weil er sich nicht einmal > > bemüht, auf Pakete zu reagieren - und wenn er selber pingt, dann > > geht es auf einmal doch ... > > ja eh, kann also nit daran liegen das einkommende pakete nie ankommen, sieh > t > eben bissl wie stateful firewall aus, dabei ist netamal conntrack > aktiv/geladen,.. Ja, genau das wundert mich auch so sehr. Es ist zum aus der Haut fahren: Kurz konnte ich die olsr Seite port 8000 aus dem freenet erreichen und hab' schon gedacht, es ist wirklich nur ein Problem mit Programmen, die auch auf tcp6 lauschen - aber nein: Fehlanzeige, das war nur ein "Zufall" das olsrd gerade erreichbar war. Hab' jetzt auch herausgefunden warum: harald at DevVserver:~$ ping -I 193.238.157.18 78.41.112.63 PING 78.41.112.63 (78.41.112.63) from 193.238.157.18 : 56(84) bytes of data. --- 78.41.112.63 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 4000ms Bei unseren bisherigen outgoing tests kam einfach nie die IP 193.238.157.18 zum tragen, deshalb hat's funktioniert. Also nix mit stateful firewall, sondern diese ip ist irgendwie fucked up ... ich versteh' nur noch nicht wie... Weitere Testmethode von mir: netcat im UDP modus. Vorteil: Daten sollten sofort an das Programm weitergereicht werden, ohne das irgendein tcp state involviert ist. Ergebnis: Die Daten, die über das Interface hereinkommen werden definitiv nicht weitergereicht! Nächste Idee zum debuggen: iptables mit TRACE target? Den "local" routing table könnte man auch noch genauer unter die Lupe nehmen. > hab nun grad ne aonip, und mit dieser keine probleme mitm devVserver Ja, es sind nur die freenet IPs betroffen, sonst scheint echt alles zu gehen. Willst nicht (zur Sicherheit) einmal probieren, die rules zu deaktivieren? Muss ja nur für ein paar Sekunden sein... Jedenfalls fällt mir sonst nichts anderes ein, wo beide freenet ranges drinnen stehen. Liebe Grüße, Harald From (spam-protected) Wed Jan 28 17:49:49 2009 From: (spam-protected) (Harald Geyer) Date: Wed, 28 Jan 2009 17:49:49 +0100 Subject: [Dump] lichtwicht olsr restart Message-ID: Hi! Der lichtwicht hat heute einen Teil vom Funknetz geblackholed (keine Ahnung, warum meine route da ueberhaupt drueber ging) weil er die route zu 78.41.112.2 "vergessen" hat (also olsr wusste die route, aber der kernel nicht). Hab' einen olsrd restart am lichtwicht gemacht ... JFYI Ueberhaupt macht der olsrd gerade recht viel komische Sachen, leider flappen die routen zu schnell, als dass ich ernsthaft was debuggen koennte. Wer maintained denn jetzt eigentlich den viviroof, wo du nicht da bist? Liebe Gruesze, Harald From (spam-protected) Wed Jan 28 20:56:39 2009 From: (spam-protected) (Felix Ehritz) Date: Wed, 28 Jan 2009 20:56:39 +0100 Subject: [Dump] lichtwicht olsr restart In-Reply-To: References: Message-ID: Danke das hat auch erklärt warum mein netz fast überhaupt nicht gefunkt hat (hp4) obwohl ich alle routerboards gesehen habe mit der winbox. Mit freundlichen Grüßen felix -----Ursprüngliche Nachricht----- Von: dump-bounces at lists.funkfeuer.at [mailto:dump-bounces at lists.funkfeuer.at] Im Auftrag von Harald Geyer Gesendet: Mittwoch, 28. Jänner 2009 17:50 An: Markus Kittenberger Cc: dump at lists.funkfeuer.at Betreff: [Dump] lichtwicht olsr restart Hi! Der lichtwicht hat heute einen Teil vom Funknetz geblackholed (keine Ahnung, warum meine route da ueberhaupt drueber ging) weil er die route zu 78.41.112.2 "vergessen" hat (also olsr wusste die route, aber der kernel nicht). Hab' einen olsrd restart am lichtwicht gemacht ... JFYI Ueberhaupt macht der olsrd gerade recht viel komische Sachen, leider flappen die routen zu schnell, als dass ich ernsthaft was debuggen koennte. Wer maintained denn jetzt eigentlich den viviroof, wo du nicht da bist? Liebe Gruesze, Harald _______________________________________________ Dump mailing list Dump at lists.funkfeuer.at http://lists.funkfeuer.at/mailman/listinfo/dump From (spam-protected) Fri Jan 30 21:15:40 2009 From: (spam-protected) (Markus Kittenberger) Date: Fri, 30 Jan 2009 21:15:40 +0100 Subject: [Dump] lichtwicht olsr restart In-Reply-To: References: Message-ID: <4095b6c00901301215k34643ae0p1222eff50173e69f@mail.gmail.com> danke fürs rebooten das liegt daran das ich den olsr von fff 1.6.36 auf etlichen knoten installiert hab um zu sehen wieviel blödsinn der macht,.. d.h. das war u.a. expected behaviour,.. dummerweise bin ich in urlaub gefahren ohne auf alten olsr downzugraden,.. lg MArkus 2009/1/28 Harald Geyer > Hi! > > Der lichtwicht hat heute einen Teil vom Funknetz geblackholed (keine > Ahnung, warum meine route da ueberhaupt drueber ging) weil er die > route zu 78.41.112.2 "vergessen" hat (also olsr wusste die route, aber > der kernel nicht). > > Hab' einen olsrd restart am lichtwicht gemacht ... JFYI > > Ueberhaupt macht der olsrd gerade recht viel komische Sachen, leider > flappen die routen zu schnell, als dass ich ernsthaft was debuggen koennte. > > Wer maintained denn jetzt eigentlich den viviroof, wo du nicht da bist? > > Liebe Gruesze, > Harald > > -------------- next part -------------- An HTML attachment was scrubbed... URL: