<p>fyi</p><p>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,..<br>
.<br>hab ich heut mal austesten wollen wieviel cpu das denn wirklich kostet,..<br>.<br>und die ergebnisse sind überraschend (unmessbar) niedrig, ...<br>.<br>also das testsetup:</p><p>ein buffalo (heunord) mit freifunkfirmware, mit ner kleinen outdoor-antenne, d.h auch ein bißchen noise von der stadt<br>
und im grunde nur ein nachbar mit 5,5mbit wlanrate (heuklein)<br>.<br>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<br>
mit ca 2,5 mbit netto, untrig als testtraffic bezeichnet.<br>.<br>und zum verifizieren ob denn die angeblich freie cpu-time auch wirklich frei ist, hab ich wget -O /dev/null <a href="http://127.0.0.1/cgi-bin-dev-zero.bin">http://127.0.0.1/cgi-bin-dev-zero.bin</a> gmacht (dessen throughput nachkontrollierterweise auch immer linear zur cpuload der dabei beteiligten prozesse war (httpd,cat und wget)) untrig als testload summiert angegeben<br>
.<br>und nun die testergebnisse (cpu load von top -d 60)<br></p><p><p>---</p><p>ohne wlan traffic von/zu heuklein:</p><p>95% testload <br>(und mutmasslich 5% kernelzeugs)<br></p><p>---</p><p>mit wlantraffic von heuklein zu heunord:</p>
<p>86% testload<br>5% wget (testtraffic)<br></p><p>d.h 91% in summe<br>d.h. 4% fehlten (zu den obigen 95%)<br>diese 4% rechne ich mal dem kernel/wlanteriber zu, der ja den testtraffic ja auch verarbeiten musste,..</p><p>----</p>
<p>mit wl monitor 1</p><p>86% testload<br>5% wget (testtraffic)<br>also immer noch 91% in summe<br></p><p>----</p><p>und dann noch zusätzlich tcpdump -s 1800 -ni prism0 > /dev/null</p><p>82% testload<br>4.6% testtraffic<br>
4.1% tcpdump<br></p><p>in summe immer noch 90,7%</p><p>---</p><p>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...)<br>
(und die anderen prozesse hatten da in summer wiederum knapp 91%)<br></p><p>---</p><p>mein schluss ist, das aktivieren und auch nutzen des prism0 monitor interfaces macht keinerlei (bzw extrem wenig) zusätzlicher (kernel-) load<br>
.<br>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,..</p>
<p>lg Markus</p><p></p></p>