Airtime script überarbeitet (respondd + meshviewer/hopglass)

wusel · 11. Juni 2016 um 00:39

Hmm. Wäre latent schön, könnten wir uns auf den Pfad der Daten einigen, dann kann das auch mal zentral in MV/HG/MF/… eingebaut werden uns tut einfach …

Die initialen Daten wurden in nodeinfo.wireless als airtime2, airtime5 und chan2, chan5 publiziert, über die Aufteilung statistics/nodeinfo kann man reden.

act2 & bus2 statt airtime2, hmm, der orginale Ansatz von @danielkrah sah vor, ein Datum zu publizieren; welchen Sinn macht es, die Rotdaten zu pushen und dann im Anzeigefrontend berechnen zu lassen?!

danielkrah · 11. Juni 2016 um 02:47

evtl sollte man sich noch mal horst anschauen ob es damit nicht eleganter geht

fuzzle · 11. Juni 2016 um 02:49

@wusel … keinen Sinn, wie auch das man die gesamtsumme nimmt ? = airtime über uptime, macht auch keinen grossen sinn, ich schreib da montag was um und präsentiere, wäre dabei für strukturen offen,
ich möchte je band haben
channel, busytime in je {24haverage, 24hmin, 24hmax}, letzte5min in rx-tx aufgeschlüsselt

@danielkrah horst is super, aber nicht auf 4mb geräten zu bekommen … ausserdem interessieren mich die werte letztendlich aufbereitet in der karte

adorfer · 11. Juni 2016 um 16:47

Der Kanal und HT-Mode ist essentiell wichtig für die Analyse, wenn man da in Nachbarschaft mehrere Nodes stehen hat in einem Mesh-LAN und überlegt, ob/wie man Kanäle und HT-Mode shiften könnte. (Daher muss es sinnvollerweise auch via Hopglass in eine Metrik für den Prometheus/Grafana laufen, damit man sich das 'über Zeit" anschauen kann.)

fuzzle · 13. Juni 2016 um 02:52

so, hier schonmal der shell teil - des eigenen gluon-modules…
ergibt dann folgendes
(diese Dateien müsste man in respondd mit einweben und in hopglass auswerten - coming soon)

0 root@fuzzle_solar:/tmp/xtra# head -n1 *
==> 2gbus <==
13621
==> 2gbus24h <==
42112
==> 2gbus24havg <==
8367
==> 2gbus24hmax <==
1018
==> 2gbus24hmin <==
988
==> 2gtotal <==
59892
==> 2gtotal24h <==
268010
==> 2gtotal24havg <==
2712
==> 2gtotal24hmax <==
1800
==> 2gtotal24hmin <==
7279
==> 2gtx <==
2949
==> 2gtx24h <==
11436
==> 2gtx24havg <==
2712
==> 2gtx24hmax <==
107
==> 2gtx24hmin <==
83
==> batif <==
ibss0
==> batttvn <==
239
==> channel <==
1

mit den werten kann man dann sehr gut Dinge verechnen und so … als bonus ist auf dem Knoten dann ein file der letzten 24 std.
wie wirds gemacht … hier das dazugehörige script (für nur 2g)

 cat /lib/gluon/airtime/airtime2.sh
#!/bin/sh 
# Setup once at runtime ...
# ... after at least 5 minutes of uptime have passed:
uptime=`awk </proc/uptime 'BEGIN{uptime=0;} {uptime=sprintf("%d", $1);} END{print uptime;}'`
if [ $uptime -lt 300 ]; then
  echo "Waiting to pass 300 seconds of uptime for stabilizing."
  exit 0
fi

# get actual airtime
channel=$(iw client0 survey dump |grep "in use" -A5|grep -o "24.."|head -n1)
total=$(iw client0 survey dump |grep "in use" -A5|grep active|grep -o "[0-9]*")
tx=$(iw client0 survey dump |grep "in use" -A5|grep transmit|grep -o "[0-9]*")
busy=$(iw client0 survey dump |grep "in use" -A5|grep busy|grep -o "[0-9]*")

mkdir -p /tmp/xtra
if [ ! -f /tmp/2gtotallast ]; then echo 0 > /tmp/2gtotallast; fi
if [ ! -f /tmp/2gtxlast ]; then echo 0 > /tmp/2gtxlast; fi
if [ ! -f /tmp/2gbuslast ]; then echo 0 > /tmp/2gbuslast; fi

# calc airtime to file
echo $(( $total - $(cat /tmp/2gtotallast|tail -n1) )) > /tmp/xtra/2gtotal
echo $(( $tx - $(cat /tmp/2gtxlast|tail -n1) )) > /tmp/xtra/2gtx
echo $(( $busy - $(cat /tmp/2gbuslast|tail -n1) )) > /tmp/xtra/2gbus

# calc24h avg max min
sumtotal=0
date +%M |grep [0-6]0 && for line in $(cat /tmp/xtra/2gtx24h); do let sumtotal+=$line; done 
date +%M |grep [0-6]0 && echo $(( $sumtotal / $(cat /tmp/xtra/2gtotal24h|wc -l) )) > /tmp/xtra/2gtotal24havg
cat /tmp/xtra/2gtotal24h|sort -n|tail -n1 > /tmp/xtra/2gtotal24hmin
cat /tmp/xtra/2gtotal24h|sort -n|head -n1 > /tmp/xtra/2gtotal24hmax
sumtx=0
date +%M |grep [0-6]0 && for line in $(cat /tmp/xtra/2gtx24h); do let sumtx+=$line; done
date +%M |grep [0-6]0 && echo $(( $sumtx / $(cat /tmp/xtra/2gtx24h|wc -l) )) > /tmp/xtra/2gtx24havg
cat /tmp/xtra/2gtx24h|sort -n|tail -n1 > /tmp/xtra/2gtx24hmin
cat /tmp/xtra/2gtx24h|sort -n|head -n1 > /tmp/xtra/2gtx24hmax
sumbus=0
date +%M |grep [0-6]0 && for line in $(cat /tmp/xtra/2gbus24h); do let sumbus+=$line; done
date +%M |grep [0-6]0 && echo $(( $sumbus / $(cat /tmp/xtra/2gbus24h|wc -l) )) > /tmp/xtra/2gbus24havg
cat /tmp/xtra/2gbus24h|sort -n|tail -n1 > /tmp/xtra/2gbus24hmin
cat /tmp/xtra/2gbus24h|sort -n|head -n1 > /tmp/xtra/2gbus24hmax

# write act to tmp file,
echo $total > /tmp/2gtotallast
echo $tx > /tmp/2gtxlast
echo $busy > /tmp/2gbuslast

# write and limit to 24h (=1440 lines per file)
echo $((($channel - 2407 )/ 5)) > /tmp/xtra/channel
cat /tmp/xtra/2gtotal >> /tmp/xtra/2gtotal24h ; cat /tmp/xtra/2gtotal24h |tail -n 1440 > /tmp/2gtotaltmp ; mv /tmp/2gtotaltmp /tmp/xtra/2gtotal24h
cat /tmp/xtra/2gtx >> /tmp/xtra/2gtx24h ; cat /tmp/xtra/2gtx24h |tail -n 1440 > /tmp/2gtxtmp ; mv /tmp/2gtxtmp /tmp/xtra/2gtx24h
cat /tmp/xtra/2gbus >> /tmp/xtra/2gbus24h; cat /tmp/xtra/2gbus24h |tail -n 1440 > /tmp/2gbustmp ; mv /tmp/2gbustmp /tmp/xtra/2gbus24h

# bonus
batctl gwl |grep = |cut -d")" -f1|grep -o [0-9]*$ > /tmp/xtra/batttvn
batctl gwl |grep = |cut -d"]" -f1|grep -o [0-9a-zA-Z-]*$ > /tmp/xtra/batif

fuzzle · 14. Juni 2016 um 21:50

@adorfer und co
das script is soweit fertig und funktioniert … was fehlt ist die koreckte position des patches
(klappt bisher nur manuell … also patch anwenden dann compile dann install , der vollständigkeit halber hier auch nochmal die zur repsondd.so gehörige history)

patch package/gluon-respondd/src/respondd.c patches/packages/gluon-respondd/0001-respondd.patch 
 2070  for file in $(find -name respondd.c |grep "gluon-respondd"); do ls -la $file; done
 2071  patch ./openwrt/build_dir/target-mips_34kc_uClibc-0.9.33.2_gluon-ar71xx-generic/gluon-respondd/respondd.c patches/packages/gluon-respondd/0001-respondd.patch 
 2072  make package/gluon-respondd/compile GLUON_TARGET=ar71xx-generic
 2073  make package/gluon-respondd/install GLUON_TARGET=ar71xx-generic
 2074  for file in $(find -name respondd.so |grep "gluon-respondd"); do ls -la $file; done

da ist ein ibss0 identifier mit reingerutscht der ohne funktion ist, der fliegt vermutlich wieder raus
in dem git von airtime (siehe 1. post) ist das hinterlegt, bisher auch ohne ht-mode und ohne 5g - beides nicht mein fokus, für änderungen aber offen …
und was auch noch nicht bearbeitet is, das möchte noch in schön in den meshviewer … aus den werten kann man ja nun viel machen.

in der nodeinfo json sieht das dann so aus …
0 root@fuzzle_solar:/# gluon-neighbour-info -d ::1 -p 1001 -t 1 -c 1 -r nodeinfo

{"software":{"autoupdater":{"branch":"support","enabled":false},"batman-adv":{"version":"2013.4.0","compat":14},"fastd":{"version":"v18","enabled":true},"firmware":{"base":"gluon-v2016.1-167-gffd1f0b","release":"v0000.externffgt"},"status-page":{"api":1}},"network":{"addresses":["fdf0:9bb:7814:a630:c66e:1fff:fe2d:4dee","2a03:2260:100e:23:c66e:1fff:fe2d:4dee","fe80::c66e:1fff:fe2d:4dee"],"mesh":{"bat0":{"interfaces":{"wireless":["f2:12:b5:a9:fd:7a"],"tunnel":["f2:12:b5:a9:fd:78"]}}},"mac":"c4:6e:1f:2d:4d:ee"},"owner":{"contact":"kaulquappen supäää"},"system":{"role":"node","site_code":"fffr"},"node_id":"c46e1f2d4dee","hostname":"fuzzle_solar","hardware":{"model":"TP-Link TL-WR841N\/ND v9","nproc":1},"wireless":{"2gbus":"19368","2gbus24havg":"8598","2gbus24hmax":"12116","2gbus24hmin":"6504","2gtotal24havg":"2434","2gtotal24hmax":"12133","2gtotal24hmin":"9475","2gtx":"5956","2gtx24havg":"2434","2gtx24hmax":"1157","2gtx24hmin":"727","batif":"ibss0","ibss0":null,"batttvn":"223","channel":"1"}}

fuzzle · 26. Juni 2016 um 21:41

so hier das zwischenergebnis … das ist noch nicht ganz sauber … aber funktioniert
zu sehen unter

die neuen Teile darin : channel, uplinkIF, ttvn, airtime_total/busy, airtime_total/tx , tx/rx

based on
https://cccfr.de/git/viisauksena/meshviewer2

danielkrah · 27. Juni 2016 um 03:56

adorfer · 27. Juni 2016 um 04:19

Wie wird da die Airtime gerechnet? Gleitendes Mittel über die letzten x Minuten? Oder reset des Counters am Ende des Messintervalls (und dessen Resportigs)?

Die alte Version (vom Christoph) hatte wohl nur „Airtime-Auslastung seit Geräte-Boot“ gerechnet.

fuzzle · 27. Juni 2016 um 13:40

ja @adorfer , das ist hier alles schon breit ausgetreten, die Ursprungsversion macht nur
gesamt airtime/ busy airtime … wobei busy = rx+tx ist.
Hier wird jede Minute je up-airtime / busy bzw up-airtime / tx … die avg airtime rechnet die letzten 24 std avg.
Zeile 2 und 3 sind redundant - geben nur unterschiedliche verhältnisse an.
der „fehler“ von @danielkrah kommt aus nem fehler im airtime script - da wurde mit falschen Werten gerechnet …
kann man alles sehen wenn man die doch recht simplen scripte ansieht, bzw. sich die je letzten commits ansieht.

danielkrah · 27. Juni 2016 um 13:56

mir gings dabei um das rauslaufende div

aber der wert von 400 ist natürlich auch falsch ^^

PetaByteBoy · 27. Juni 2016 um 19:09

Ohne das alles zu lesen übe ich mal Kritik am Format:

Die Daten müssen unbedingt in die „statistics“, nicht in die „nodeinfo“.
Die Daten, die nicht zur Airtime gehören sollten
- in ein seperates Paket
- seperat (falls eins nicht angenommen wird) als PR ins Gluon
Sinnvollere Namen
- Aufteilung in „rx“, „tx“ und „other“
- verschachtelt in JSON-Objekten (bsp.: nodeinfo.statistics.wireless.24g.rx, nodeinfo.statistics.wireless.24g.rx)
- min- und max-Werte sind überflüssig, können im Nachhinein serverseitig berechnet werden (Grafana)

Meine 2 Cents zur Darstellung:

Die 4 Balken sehen ziemlich ulkig aus und bei 5 GHz sind es dann 8 Balken. Man könnte auch „tx“, „rx“ und „other“ in einem Balken zusammenfassen, der in 3 Teile aufgeteilt ist. Damit hätte man einen Airtime-Graphen für 2.4 GHz und einen für 5 GHz. Optional könnte man noch einen vollständigen Balken für 24h avg anbieten.

fuzzle · 27. Juni 2016 um 21:04

@PetaByteBoy ja - so ziemlich alles korrekt, einziger Punkt - die statistics daten werden, soweit ich weis , bei (vermeintlich) offline nicht angezeigt, fliegen aus der nodes.json raus …
allerdings werden die nodeinfo daten viel weniger oft abgefragt.

würd mich riesig freuen wenn das Paket anderweitig viel weiter entwickelt wird, und zu einer schöneren Darstellung kommt.

PetaByteBoy · 28. Juni 2016 um 13:34

Sollen die Daten doch rausfliegen wenn sie nicht aktuell sind…

fuzzle · 28. Juni 2016 um 13:59

nun, ich find die meisten daten da aber sehr interessant, zumindest rx/tx und 24h avg, sowie ttvn und uplinkIF.
aber darüber streiten is müssig - in vielem deiner Punkte haste recht, muss halt jemand machen, bzw. muss man sich einigen was man wie

in Gluon reinbringt
in den Meshviewer/hopglass reinbringt
das bedeutet zwangsweise sich auf eine datenstruktur zu einigen … wie bspw. von dir vorgeschlagen
(achtung ist nicht die aktuell verwendete!)
statistics . wireless . 2g . txtime
statistics . wireless . 2g . rxtime
statistics . wireless . 2g . alltime
statistics . wireless . 2g . avgbusy
statistics . wireless . 5g . txtime
statistics . wireless . 5g . rxtime
statistics . wireless . 5g . alltime
statistics . wireless . 5g . avgbusy
statistics . wireless . channel
statistics . wireless . ttvn
statistics . wireless . batgw
wie ein entsprechendes script dann aussähe ist sekundär …

PetaByteBoy · 28. Juni 2016 um 14:01

Dafür gibt es Statistiken d.h. Prometheus und Grafana.

Das batgw gehört ja nicht wirklich zu wireless. Es könnte ja auch das LAN-/WAN-If sein.

fuzzle · 28. Juni 2016 um 14:04

so nen forum is denkbar ungeeignet um gemeinsam an code zu arbeiten, oder sich zu einigen …
kann das sein das du email antworten benutzt und den nacheditierten beitrag folglich nicht gelesen hast ?

PetaByteBoy · 28. Juni 2016 um 14:09

Nein, ich habe einfach geantwortet bevor du deinen Post editiert hast. Dein Edit war laut Forum vor 3 Min, mein Post vor 6 Min. Bei Email-Antworten wäre ein entsprechendes Icon oben rechts zu sehen.

fuzzle · 28. Juni 2016 um 14:14

wie auch immer, mir ist nicht klar wie es weitergehen kann/soll ? für konkrete vorschläge offen …
wobei ich sagen muss, das ich wenig motivation hab da gerade „groß“ was zu ändern, da es für unsere Freiburger verhältnisse gerade passt - und ich finde auch ausreichend gut dokumentiert, bzw . für Pull requests auch ausreichend offen im Netz steht.
Das da viel möglich ist, und einiges Sinnvoller ist steht ausser frage.
(btw. grafana nutzt schlicht nicht jeder - daher würd ich das als dependency unschön finden, zumal die knoten die daten ohne probleme liefern können (avg, min und max wobei die relativ wenig gehalt haben))

danielkrah · 28. Juni 2016 um 15:08

die einfache airtime pro Frequenz reicht für alles andere gibt es prometheus / opennms + grafana