Airtime script überarbeitet (respondd + meshviewer/hopglass)

fuzzle · 9. Juni 2016 um 00:20

hab das airtime script überarbeitet, alles was ich fand basierte auf alfred, oder anounced

soweit ich verstanden habe, ist es nicht mehr trivial Informationen zu nodeinfo oder statistics hinzuzufügen.
Und natürlich ist das ganze Komplex - bis es dann mal ersteinmal im Kartenbackend (also der nodes.json) und folglich hopglass bzw dem meshviewer ist. In diesem Beispiel funktioniert das NUR auf dem Knoten

das packet findet sich hier

Was sehr unschön ist, bzw edits und Stand der Dinge

das ich noch keine Lösung für die angepasste respondd.so hab … gibt es die api strukturen garnicht mehr? Dort wo man in statistics.d und nodeinfo.d bei announced einfach weitere Daten hinterlegen konnte? - es scheint da könnte man vorcompiliertes zeug ablegen, unter /lib/gluon/respondd
der Patch der da ist - funktioniert nur von Hand … und refferenziert noch falsch
~~es befinden sich nun eine Menge Dateien in /tmp/xtra , die werden via alfred/respondd gesendet (siehe folgende Posts) die müssten nur noch in der Karte ausgewertet werden~~
man möchte die daten eher in statistics als in nodeinfo haben? höhere aktualisierung, aber keine offline info??!!
die airtime ist im moment noch onlinetime / (rxtime+txtime) , also eher ein Durchschnittswert über die uptime, als der aktuelle airtime wert. - interessant dürfte in der Regel aber die akute Airtime sein! die Datenbasis erlaubt nun alles, näheres im Git
~~Es wird nicht aufgeschlüsselt zwischen TX und RX - das könnte im Einzelfall auch sehr interessant sein, denn so kann ich heavy-used-nodes nicht von eher nur lauschenden unterscheiden.~~

ich verweise mal selber direkt hierdrauf - aktueller Stand der Dinge

Jason · 9. Juni 2016 um 12:51

Hallo,

bezüglich der Airtime haben wir hier in Frankfurt auch etwas experimentiert.
Herausgekommen ist ein Packages, welches z.z. respondd UND alfred/LUA gleichzeitig unterstützt.
Demnächst werden wir den alfred/LUA-Teil aber komplett rauswerfen. Der ist in unserem Package nur komplizierter Balast und wir brauchen den hier in Frankfurt nicht mehr.

https://github.com/freifunk-ffm/packages/tree/master/ffffm/ffffm-additional-wifi-json-info

Da das Package z.z. noch nicht dokumentiert ist, hier ein/zwei Anmerkungen:

Das Package ist generell für respondd ausgelegt/vorgesehen
Die alfred/Lua-Skripte fungieren als Wrapper, welche die respondd *.so linken
Werden Tests beim Bauen aktiviert, so kann man z.B. mit folgendem Befehl die Airtime und die verwendetet Channel ausgeben lassen

ffffm-respondd-test /lib/gluon/respondd/wireless.so

P.S.
Auf einem Router funktioniert generell ein lokaler Test wie folgt:

gluon-neighbour-info -d ::1 -p 1001 -t 1 -r nodeinfo
gluon-neighbour-info -d ::1 -p 1001 -t 1 -r statistics

P.S.S
Ich bin nicht der Entwickler des Packages :o)

Jason · 9. Juni 2016 um 13:00

Jau, da habe ich auch gerade dran zu knacken!

fuzzle · 9. Juni 2016 um 13:21

danke für den link, bin gespannt und schau da mal rein … ist das in ff-ffm irgendwo im meshviewer/hopglas als ergebnis zu sehen ? spontan hab ich da nix gesehen.

und zu dem „aktualitätsding“, behelfsmäßig für die aktualität schreib ich im shell script halt sowas wie
(hoffe das nicht zu kryptisch, wenn ich das sauber hinschreib , ersetz ich das hier …
generell speichert es den letzten wert in act2tmp zwischen, und zieht den vom act2neu ab.)

# nur nen beispiel - bin grad nicht daheim
if act nicht existiert ..
    act2=1
else
   act2=$(cat /tmp/act2tmp)
fi
act2neu=$(command für neue act)
echo $(($act2neu - $act2)) > /tmp/act2
act2tmp=$act2neu

ich schreib ja gerne die letzten 24std in den tmp ordner … daher ordentlich dann …und gleich average und max und min mit ausgeben … die kann man dann auch easy einbauen.

adorfer · 9. Juni 2016 um 13:43

Mag es sein, dass die eine „Wifi-Sektion“ immer leer bleibt?

Ausserdem gab’s irgendwie Verwirrung, dass der PR auf den Hopglass vom (afail vom @danielkrah ) die Labels für das 2er-Band unter „2.4“ erwartet, nicht unter „2“. Und dann irgendwie „Gateway-Netxtnode“ vs „Nextnode“, wenn ich’s richtig gesehen habe.

Jason · 9. Juni 2016 um 13:47

Sagen wir mal so, unsere Package-Entwicklung kommt zur zeit hinter der Hopglass-Entwicklung nicht hinterher.
Da müssen wir noch etwas Gass geben, oder warten bis sich da ein halbwegs stabieler Standard etabliert hat.

Jason · 9. Juni 2016 um 14:04

Bei respondd oder Alfred/LUA?

Mit unserem Package sollte das mittels respondd bei einem 841’er z.z. noch so aussehen:

root@Outerspace:/lib/gluon/respondd# ffffm-respondd-test ./wireless.so

statistics:
{
  "wireless":{
    "airtime2":0.26547019279359296
  }
}
nodeinfo:
{
  "wireless":{
    "chan2":1
  }
}

Jason · 9. Juni 2016 um 14:07

Sporarisch hier:
https://hopglass.ffm.freifunk.net/#!v:g;n:c46e1fb627da

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.