Airtime script überarbeitet (respondd + meshviewer/hopglass)

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

@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

1 Like

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.)

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
1 Like

@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"}}
2 Likes

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

3 Likes

1 Like

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.

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.

1 Like

mir gings dabei um das rauslaufende div :smiley:

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

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.

2 Likes

@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.

Sollen die Daten doch rausfliegen wenn sie nicht aktuell sind…

1 Like

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

  1. in Gluon reinbringt
  2. 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 …

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.

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 ?

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.

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))

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

Dir vielleicht, mir nicht, da es ein Unterschied zwischen RX und TX Airtime (Nein, das ist nicht zwangsläufig im gleichen verhätlnis wie TX/RX-volume oder TX/RX-packets, da die Info zur jeweiligen MCS fehlt.) gibt.
Und damit die Ableitung, wo Optimierungspotential hinsichtlich des Antennenstandortes ist.

Ausserdem wäre es schön, wenn zukünftige Chipsätze, zwischen Airtime des eigenen APs und der von anderen (auf gleicher Frequenz) unterscheiden könnten.