[Dump] Test: wieviel cpu load denn wirklich bei monitor mode

[Markus Kittenberger]

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: <http://lists.funkfeuer.at/pipermail/dump/attachments/20090105/4efea696/attachment.html>