Unitymedia Auslastung des eigenen Segments ansehen (reloaded)

MartinP_Do · 23.11.2019

Eine weitere Anregung, und dann noch Fragen:

Anregung: Das Ausgabeverzeichnis für die Grafiken im Aufruf festlegbar machen - so kann man z. B. die Dateien direkt in das Dokumentenverzeichnis eines Webservers schicken.

Frage: Ich habe ja das Skript mit "nohup" von der Konsole getrennt - jetzt sehe ich den Prozess aber gar nicht mehr mit ..

Code:

ps -ef

sondern nur noch mehrere Prozesse, die vom Skript gestartet wurden.

Code:

 pi 3174 1 13 Nov19 ? 12:22:14 awk -f CableLoadMonitor.awklib -f CableLoadMonitor_3174.awk
...
pi 9960 3174 0 11:52 ? 00:00:00 sh -c /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvb
pi 9961 9960 3 11:52 ? 00:00:00 timeout 10 dvbtune -f 570000000 -s 6952 -qam 256
pi 9962 9961 1 11:52 ? 00:00:00 dvbtune -f 570000000 -s 6952 -qam 256

usw...

1) wie kriege ich die alle gestoppt, ohne den Holzhammer "shutdown -r now" rauszuholen?

2) Wenn ich das Verwalten systemctl überlasse - Stoppt "systemctl stop cableloadmonitord" auch die ganze Herde Prozesse sicher (z. B. weil sie "Kinder" eines gemeinsamen Vaterprozesses sind)?

sparkie · 23.11.2019

MartinP_Do schrieb:
Anregung: Das Ausgabeverzeichnis für die Grafiken im Aufruf festlegbar machen - so kann man z. B. die Dateien direkt in das Dokumentenverzeichnis eines Webservers schicken.

ok, ist vermerkt

1) wie kriege ich die alle gestoppt, ohne den Holzhammer "shutdown -r now" rauszuholen?

Code:

kill 3174

2) Wenn ich das Verwalten systemctl überlasse - Stoppt "systemctl stop cableloadmonitord" auch die ganze Herde Prozesse sicher (z. B. weil sie "Kinder" eines gemeinsamen Vaterprozesses sind)?

ja, weil wegen des vorangestellten '-' im PID-File schickt er die Signale an die Prozessgruppe und nicht nur an einen einzelnen Prozess.

srxx · 23.11.2019

Ich habe bei mir jetzt auch mal die restlichen Kanäle hinzugefügt zu den 24, die von meiner FritzBox verwendet werden.
Die Auslastung bei dem einen Kanal (770) ist recht merkwürdig, teilweise wird 0 geloggt, und dann plötzlich 13M, während die anderen nicht so extrem schwanken. Woran könnte das liegen?

rv112 · 23.11.2019

Eventuell hängt da nur eine Hand voll Modem drauf?

MartinP_Do · 23.11.2019

Habe mehrere Änderungen auf einmal gemacht -sollte man nicht machen, habe gleichzeitig auf Start durch Systemctl umgestellt, die Kanalzahl auf 31 erhöht, und auch eine Wochengrafik angefangen.

Kann es sein dass mein pi B+ (weder 2 noch 3) zu wenig Speicher hat, um eine Woche im RRD zu halten (siehe "malloc fetch data area"?

Code:

the RRD does not exist
(re)creating the RRD base
rrdtool graph fails
exiting...
ERROR: malloc fetch data area
CMD: </home/pi/proj/docsis-cable-load-monitor/CableLoadMonitor -d 0 -i -f 474:482:490:498:522:530:538:546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770 2>&1>
evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 31 ] 474 482 490 498 522 530 538 546 554 562 570 578 586 594 602 618 626 634 642 650 658 666 674 682 690 698 706 746 754 762 770
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
dvbtune: ignore bit errors
display mode: standard
generating graph for: 1h recording length, size 1400x1000 pixels
generating graph for: 6h recording length, size 1400x1000 pixels
generating graph for: 1d recording length, size 1400x1000 pixels
generating graph for: 7d recording length, size 1400x1000 pixels
rrdtool graph fails
exiting...
ERROR: malloc fetch data area
CMD: </home/pi/proj/docsis-cable-load-monitor/CableLoadMonitor -d 0 -i -f 474:482:490:498:522:530:538:546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770 2>&1>
evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 31 ] 474 482 490 498 522 530 538 546 554 562 570 578 586 594 602 618 626 634 642 650 658 666 674 682 690 698 706 746 754 762 770
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
dvbtune: ignore bit errors
display mode: standard
generating graph for: 1h recording length, size 1400x1000 pixels
generating graph for: 6h recording length, size 1400x1000 pixels
generating graph for: 1d recording length, size 1400x1000 pixels
generating graph for: 7d recording length, size 1400x1000 pixels
pi@raspberrypi:~/proj/docsis-cable-load-monitor $

MartinP_Do · 23.11.2019

Bevor ich mich weiter darum kümmere, ob ich das mit dem System Demon noch schaffe, habe ich erstmal an der Kommandozeile gefeilt, und festgestellt, dass auf den Kanälen 474 MHz bis 538 MHz nichts los ist - anscheinend sind in meinem Segment nur 24 Kanäle in Benutzung ...

Daneben hat der DVB-T/-C Kombistick nach einem Reboot des Raspberry Pi wieder gezickt.
Erst kamen nur "Null" Werte auf allen Kanälen.
Durch ein

Code:

w_scan -fc

habe ich den Stick wieder auf DVB-C gestellt bekommen ...

sparkie · 23.11.2019

MartinP_Do schrieb:
Kann es sein dass mein pi B+ (weder 2 noch 3) zu wenig Speicher hat, um eine Woche im RRD zu halten (siehe "malloc fetch data area"?

1 Woche sollte selbst auf dem pi B+ kein Problem sein. Ich hatte allerdings bis zum 15. Nov einen Bug drinnen, der versehentlich die 10x fache Speichermenge angefordert hat (also fuer 10 Wochen statt fuer 1 Woche)

bug fix calculating the correct recording length · sp4rkie/docsis-cable-load-monitor@4c24bee

hast du evtl. noch diese alte Version?

MartinP_Do · 23.11.2019

Bei mir steht in Zeile 102 bereits...

Code:

HIST_SIZE_CFG = a[2] * RRA_STEPS_CFG

erst heute das Git repository geklont...

sparkie · 23.11.2019

laufen evtl. zuviele Prozesse? Ist Graphik aktiv? Evtl. ist im /boot/config.txt zuviel Speicher fuer was anderes reserviert? Am besten mal schrittweise die Aufzeichnungslaenge mit der -r Option reduzieren bis es geht.

MartinP_Do · 23.11.2019

Habe mir erstmal geholfen, indem ich eine 3-Tages-Grafik eingeführt habe.
Das ist ein Headless mit Raspbian light, also ohne Grafik etc.
Das Ding steht im Keller in einem Wandschrank neben dem Hausanschluss - da ist Grafik wenig sinnvoll ...

Code:

# NOT required if Sundtek hardware is NOT in use - gives error messages then # LD_PL = "LD_PRELOAD=/opt/lib/libmediaclient.so " LD_PL = ""
....
# default RRDGRAPH RRDGRAPH_NAME = "/var/www/html/CableLoadMonitor"
.... # feel free to add other history sizes (aka generated graphs) as well
... RRDGRAPHS[RRDGRAPHS_CNT++] = 60 * 60 * 24 * 3 " |3d"
...

Und hier noch die kleine Webseite, die ich für die Darstellung nutze

HTML:

<html>
<head><title>Segmentauslastung Unitymedia</title> <script type="text/javascript" src="http://code.jquery.com/jquery-1.4.1.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ $('#inserttext').load('CableLoadMonitor_bwidth.txt'); }); </script>
</head>
<body>
<h1>Aktuell gemessene Gesamtdatenrate im Kabelsegment: <div id="inserttext"></h1>
</div>
<br>
<a href="CableLoadMonitor_1h.png"><img width="850" height="300" src="CableLoadMonitor_1h.png"></img></a>Stunden&uuml;bersicht
<br>
<a href="CableLoadMonitor_6h.png"><img width="850" height="300" src="CableLoadMonitor_6h.png"></a>6-Stunden&uuml;bersicht</img>
<br>
<a href="CableLoadMonitor_1d.png"><img width="850" height="300" src="CableLoadMonitor_1d.png"></a>Tages&uuml;bersicht</img>
<br>
<a href="CableLoadMonitor_3d.png"><img width="850" height="300" src="CableLoadMonitor_3d.png"></a>3-Tages&uuml;bersicht</img>
</body>
</html>

und hier noch ein paar free-Ausgaben, während das Skript läuft

Rich (BBCode):

pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 37716 319344 484 86020 356040
Swap: 102396 15080 87316
pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 42176 314880 484 86024 351580
Swap: 102396 15080 87316
pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 45772 311284 484 86024 347984
Swap: 102396 15080 87316
pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 52096 304960 484 86024 341660
Swap: 102396 15080 87316
pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 52212 304836 484 86032 341544
Swap: 102396 15080 87316
pi@raspberrypi:~/proj/docsis-cable-load-monitor $ free total used free shared buff/cache available
Mem: 443080 52460 304588 484 86032 341296
Swap: 102396 15080 87316

EDIT HTML-Quellcode

MartinP_Do · 23.11.2019

Diese neue Forumssoftware scheint ein paar Probleme damit zu haben, wie Linux Zeilenumbrüche usw macht.
Mit ein paar Sekunden Verzögerung kriegt man seine schönen Listings total zerfleddert präsentiert ...

Andreas1969 · 23.11.2019

MartinP_Do schrieb:
Diese neue Forumssoftware scheint ein paar Probleme damit zu haben, wie Linux Zeilenumbrüche usw macht.
Mit ein paar Sekunden Verzögerung kriegt man seine schönen Listings total zerfleddert präsentiert ...

Ich fand die alte auch definitiv besser!

rv112 · 24.11.2019

Die Großströung heute um 20 Uhr, hat man auch in meinem Segment gesehen. Ich war davon natürlich nicht betroffen. Was ist da eigentlich immer das Problem? Fällt ja fast wöchentlich aus in letzter Zeit?

https://www.netzwelt.de/ist-down/17...en.html#utm_source=dlvr.it&utm_medium=twitter

Holzlenkrad · 25.11.2019

Bestimmt wieder der DNS-Server. Oder der IPv4 NAT Server. Deswegen bekomme ich auch nie eine der zahlreichen Großstörungen bei Vodafone und UM mit...

MartinP_Do · 25.11.2019

Muss mich wohl auch etwas mit den Grafiktool befassen.
Zwei Änderungen in der Darstellung der Kurven würden mir vorschweben:

1) Oberes Ende der Y-Skalierung schwankt nicht mit der max. Gesamtlast im Darstellungszeitraum, sondern ist immer 100 % Segmentlast, bei 24 Kanälen also 1200 MBit/s und bei 31 Kanälen 1550 MBit/s. So sieht man schneller, wie nah das Segment einer Überlast ist ...
2) Das "Gekrissel" der Einzelkanal-Kurven durch eine Skalierung mit dem 10-fachen Gewicht besser sichtbar machen - so wäre dann bei 24 Kanälen eine Einzelkanallast von nicht erreichbaren 120 MBit/s 100 % der y-Skala - damit wäre gewährleistet, dass die EInzelkurven immer unterhalb der Summenkurve bleiben, und sie wären gleichzeitig besser ablesbar ...

rv112 · 26.11.2019

Heute ist leider mein Stick wieder abgeschmiert, trotz dass der Sleep noch auf 5 steht

Holzlenkrad · 27.11.2019

rv112 schrieb:
Heute ist leider mein Stick wieder abgeschmiert, trotz dass der Sleep noch auf 5 steht

Wie viel Tage lief es vorher problemlos?
Ich habe leider bis jetzt noch keine Methode gefunden um das zuverlässig komplett zu verhindern. Nach einem Neustart des Raspberry sollte es aber wieder laufen?

Ich kann dir nochmal einen Schnipsel Code schicken, der die Fehlfunktion zuverlässig erkennt und neustartet. Dann müsstest du dafür sorgen, dass das Script dann wieder automatisch gestartet wird.

Allerdings mache ich gerade an dem Projekt recht wenig, weil sparkie ja für Dezember viele Änderungen plant und die Multi-Tuner-Funktion sicherlich viel besser umsetzen wird als ich das quick and dirty gemacht habe.
Außerdem funktioniert mein Stick nur auf dem Raspberry Pi 3, nicht aber auf dem 4er. Ich habe allerdings nur einen 3er, der gerade seine ursprüngliche Aufgabe - dem Smarthome - nachgeht. Das muss ich dann eben auf den neueren Pi umziehen...

rv112 · 27.11.2019

Lief so gut eine Woche. Ja nur ein Neustart hat geholfen.

rv112 · 28.11.2019

Gestern Abend schon wieder gecrasht. Werde vermutlich auf den einen Tuner zurück gehen.

MartinP_Do · 28.11.2019

Meine Installation läuft bisher durch
Edision Optimuss Stick und Raspberry Pi B+

Die Stelle zum Einstellen den oberen Endpunkt der Y-Achse auf den Maximalwert der Segmentkapazität habe ich wohl auch gefunden...
Das bedeutet wohl, dass der obere Grenzwert bei 40 MBit/s lst, wenn sich nicht höhere Messwerte finden:

Code:

 RRDGRAPH_Y_UPPER_LIMIT = 40 # scale Y axis to this minimum

Um die minimale Ausdehnung passend zu 24 Kanäle x 50 MBit/s zu setzen müsste man das wohl auf

Code:

 RRDGRAPH_Y_UPPER_LIMIT = 1200 # scale Y axis to this minimum

hochsetzen - korrekt?

Für meine anderen Idee, die Einzelkanäle um den Faktor 10 vergrößert darzustellen habe ich aber noch keinen Weg gefunden ...
Vielleicht wäre auch einfach eine Extra-Grafik ohne die Summe zielführender ...

Holzlenkrad · 01.12.2019

rv112 schrieb:
Gestern Abend schon wieder gecrasht. Werde vermutlich auf den einen Tuner zurück gehen.

Wie gesagt, ich bin mir sicher, dass sparkie den Multi-Tuner Support besser umsetzen wird, als ich. Ich wollte ja auch eigentlich nur herausfinden, ob und wie sehr damit ein Zeitvorteil zu erreichen ist.
Bei mir läuft das Script seit Dienstag mal wieder problemlos. Und genau das macht es ja auch so schwer, den Crash zu debuggen. Ich habe ein paar Ideen, wie man den automatisiert abfangen kann, aber da der Absturz nicht wirklich (re)produzierbar ist, muss ich immer eine ca. Woche warten zwischen Änderungen

MartinP_Do · 06.12.2019

Holzlenkrad schrieb:
Ich finde, dass die Gesamtkurve immer die Größte sein müsste. So ist es relativ unübersichtlich, leider.
Zwei bessere Möglichkeiten würden mir da einfallen, aber ich weiß nicht, ob das mit RRD tools geht:
Man könnte z.B. die Skala für die Geschwindigkeit bis 50 MBit größer ansetzen, als für die höheren Geschwindigkeiten der Gesamtauslastung. Nachteil, die Darstellung Summe ist dann nicht mehr linear.
Oder (sicherlich am schwersten) man nutzt einen Graphen für die einzelnen Kanäle und einen zweiten Graphen für die Summe (beides innerhalb einer Grafik), die man dann direkt über dem ersten platziert.

Als dritte Variante würde mir noch einfallen, dass man die einzelnen Kanäle als Fläche darstellt und die Gesamtauslastung praktisch einfach nur die Gesamtfläche dieser Kanäle ist. Aber dafür ist wohl die Auslastung der Kanäle insgesamt zu irrulär, sodass das nicht gut aussehen wird.

Bei 31 Kanälen und relativer Gleichverteilung der Last auf die Kanäle ist die Lösung mit der um den Faktor 10 gestauchten Summenlast eigentlich Gewähr dafür, dass die Summenlastkurve nicht "abtaucht".
Bei weniger Kanälen vielleicht eher nicht ...

Im Beispielbild werden ja nur 20 Kanäle ausgewertet - aber selbst da ist es irritierend, dass mancher Kanal deutlich mehr als 10 % der Last trägt (Sieht teilweise fast nach 20 % aus...) Bei Gleichverteilung trüge jeder 5%, und die Summenkurve wäre sicher oberhalb ...

Was mich am Beispielbild irritiert, ist die viele "Luft nach oben", die keine der Kurven tangiert...
Ist da noch etwas nicht astrein bei der automatischen Skalierung?

sparkie · 06.12.2019

von welcher Version stammt denn dieses Bild? Sicher nicht von einer der aktuelleren

es gibt eine Variable 'RRDGRAPH_Y_UPPER_LIMIT = 40' . DIe kannst du nach Belieben verkleinern. Ich finde es aber irritierend wenn die Skalierung dauernd herumspringt,

sparkie · 06.12.2019

multi tuner support ist jetzt im git. Ob der auto-detect fuer non-Sundtek cards funktioniert, kann ich nicht sagen. Bitte um Rueckmeldung mit *.log File wenn es Probleme gibt.

MartinP_Do · 06.12.2019

sparkie schrieb:
von welcher Version stammt denn dieses Bild? Sicher nicht von einer der aktuelleren

es gibt eine Variable 'RRDGRAPH_Y_UPPER_LIMIT = 40' . DIe kannst du nach Belieben verkleinern. Ich finde es aber irritierend wenn die Skalierung dauernd herumspringt,

Bzgl. des Springens der Skalierung hast Du natürlich auch wieder Recht ...

Unitymedia Auslastung des eigenen Segments ansehen (reloaded)

MartinP_Do

sparkie

srxx

rv112

MartinP_Do

MartinP_Do

sparkie

MartinP_Do

sparkie

MartinP_Do

MartinP_Do

Andreas1969

rv112

Anhänge

Holzlenkrad

MartinP_Do

rv112

Anhänge

Holzlenkrad

rv112

rv112

MartinP_Do

Holzlenkrad

MartinP_Do

sparkie

sparkie

MartinP_Do

Auslastung des eigenen Segments ansehen (reloaded)

Auslastung des eigenen Segments ansehen (reloaded) - Ähnliche Themen

Fast jeden Tag Internet weg für 1-2 Minuten

Täglich zwei Verbindungsabbrüche

Connectbox startet mehrmals täglich neu

OFDMA verschwindet

Nach Techniker-Besuch (ursprünglich wegen erhöhter Fehler auf Kanälen) nun Ping sprunghaft/instabil

Neueste Beiträge

Über uns

Interessante Themen

... und noch mehr