Unitymedia Auslastung des eigenen Segments ansehen (reloaded)

[boba]

Die de-cix Daten sind vermutlich über einen größeren Zeitraum ausgeglichen, deshalb sehen sie weniger gezackt aus. Außerdem sind am de-cix Millionen von Datenströmen drauf, die gleichen sich schon von selbst weitaus mehr aus als ein paar Leute an einem docsis Segment, deshalb ist der docsis Graph von vornherein glatter. Und zuguterletzt hast du doch eine Trendlinie beim docsis Graph, das ist die zugegebenermaßen etwas schlecht sichtbare blaue Linie im oberen Drittel des grün. Denkt man sich das grün weg, zeigt das einen über 24h gemittelten Wert an. Das kommt von der Zackigkeit her schon eher an das de-cix. Und die Peaks, hätte ich die auch so ausgemittelt, wären die ähnlich.

Wenn mehr Daten vorliegen, so in 3-4 Monaten, kann man schauen, ob es sinnvoll ist, den Graph etwas anders anzulegen. Die Graphen insgesamt waren ein erster Wurf, mal in einem Nachmittag zusammengebaut. Das muss noch nicht der Weisheit letzter Schluss sein. Ich habe z.B. jetzt in der Legende noch den Peak pro Kanal als Text aufgeführt, da sieht man z.B. dass es zumindest bei mir bisher bis 50.38 Mbit hoch geht. Das dürfte schon nahe am Kanal-Limit sein, und da will ich rausfinden, wie hoch das in der Realität ist. Also nicht nur in der Theorie (da sind es 55), sondern über welchen Wert es nie hinausgeht. Mein Segment ist da etwas doof als Beispiel, es ist nicht maximal ausgelastet. Deins auch nicht, das scheint so die standard normale Auslastung zu sein, die man bei Vodafone für ein Segment anstrebt.

 

[why_]

Ich habe z.B. jetzt in der Legende noch den Peak pro Kanal als Text aufgeführt, da sieht man z.B. dass es zumindest bei mir bisher bis 50.38 Mbit hoch geht. Das dürfte schon nahe am Kanal-Limit sein, und da will ich rausfinden, wie hoch das in der Realität ist. Also nicht nur in der Theorie (da sind es 55), sondern über welchen Wert es nie hinausgeht. Mein Segment ist da etwas doof als Beispiel, es ist nicht maximal ausgelastet. Deins auch nicht, das scheint so die standard normale Auslastung zu sein, die man bei Vodafone für ein Segment anstrebt.

Das täuscht, der letzte Nodesplit war vor weniger als einem Jahr, trotzdem peakt das hier abends schon wieder an den 100% über mehrere Stunden und der nächste Nodesplit ist fällig. Ende letzten Jahres war der für März eingetragen, mittlerweile hat sich das schon auf ende August geschoben.
Das Maximum liegt bei so 51,x mbit/s pro kanal.

 

[MartinP_Do]

Im DECIX-Graph gibt es nur zwei Messwerte, die geplottet werden, die Average-Kurve hat man unterhalb gefüllt dargestellt ...
Das wurde wahrscheinlich mit AREA gemacht

https://oss.oetiker.ch/rrdtool/doc/rrdgraph_graph.en.html

AREA:value[#color[#color2]][:[legend][:STACK][:skipscale][:gradheight=y]

See LINE, however the area between the x-axis and the line will be filled.

Es gibt sogar ein auskommentiertes Beispiel in @boba s Script, ungefähr bei Zeile 200

 # first write the stacked area for idx in "${!channel[@]}"; do ch=${channel[idx]} col=${color[idx]}
# append "AREA:${ch}${col}::STACK" append "LINE1:${ch}${col}::STACK" done

 

[MartinP_Do]

Das täuscht, der letzte Nodesplit war vor weniger als einem Jahr, trotzdem peakt das hier abends schon wieder an den 100% über mehrere Stunden und der nächste Nodesplit ist fällig. Ende letzten Jahres war der für März eingetragen, mittlerweile hat sich das schon auf ende August geschoben.
Das Maximum liegt bei so 51,x mbit/s pro kanal.

Kratzt es da nur abends am Limit, oder ist es durchgehend sehr hoch?
Bei letzterem könnte man ja fast vermuten, dass da ein paar Leute im Segment Blödsinn treiben ....
Blöd ist ja, dass man vor einem weiteren Segmentsplit nicht einfach das Maximum an DOCSIS 3.0 Kanälen aufschaltet...

So sieht es in meinem Segment aktuell aus - Grafik ist noch etwas zerfressen durch Experimente.




Kleine Änderungen an der Crontab und am Skript waren nötig, damit das Skript durchläuft

Crontab:

# m h dom mon dow command
0 */1 * * * /bin/bash $HOME/docsis-cable-load-monitor/cableload_graph.sh 6h >>"$HOME/logs/myscript.log" 2>&1
5 */6 * * * /bin/bash $HOME/docsis-cable-load-monitor/cableload_graph.sh 1d >>"$HOME/logs/myscript.log" 2>&1
10 0 */1 * * /bin/bash $HOME/docsis-cable-load-monitor/cableload_graph.sh 7d >>"$HOME/logs/myscript.log" 2>&1
#--------------------------

Damit das Skript in der Shell ausgeführt werden kann, müssen die Dateinamen mit vollem Pfad übergeben werden. Dann noch ein wenig Ausgabe für das Logging eingefügt

#!/bin/bash
now=$(date +"%T")
echo "cableload_graph.sh started at $now"
channels=24
#suffix="-X"
suffix=""
workdir="/home/pi/docsis-cable-load-monitor/"
rrd="${workdir}CableLoadMonitor${suffix}.rrd"

 

[MartinP_Do]

Hat eigentlich jemand etwas bzgl. "Fieberkurven" einer TC4400 in Petto? - Die nicht korrigierbaren Fehler auf dem DOCSIS 3.1 Kanal wären von Interesse - bei mir kommen täglich ein paar Millionen hinzu. Da wollte ich schauen, ob die irgendwie zufällig über die Zeit verteilt einlaufen, oder ob es da Bursts gibt, die ggfs. Ereignissen zugeordnet werden können (z. B. schwerer Müllwagen fährt durch die Straße)...

Der Standort meiner Fritzbox ist inzwischen zu einem richtigen "Meßplatz" geworden.
Vierloch Multimediadose
Data 1 -> Unitymedia Fritzbox 6591 (im selbst gebastelten - nachträglich mit Luftlöchern versehenen Wandhalter)
Data 2 -> TC 4400 zum "Mitmessen" (oben auf dem Regalbrett)
TV ->Rasberry mit DVB-C USB-Stick (offen auf die Treppenwange geschraubt)

 

[MartinP_Do]

Hat eigentlich jemand etwas bzgl. "Fieberkurven" einer TC4400 in Petto? - Die nicht korrigierbaren Fehler auf dem DOCSIS 3.1 Kanal wären von Interesse - bei mir kommen täglich ein paar Millionen hinzu.

Habe jetzt selber etwas gebastelt, basierend auf @sparkie s Skript bzgl. TC4400.

Da nur der OFDM-Kanal etwas Sorgen bereitet, habe ich das Skript angepasst, dass es aus der Kanal-Zeile mit "OFDM" SNR, Power Level und unkorriegierbare Fehler extrahiert, und in eine Text-Datei schreibt. RRD und grafische Darstellung kommen ggfs später...

Logging sieht so aus:
Format:
Datum Uhrzeit SNR Power UncorrErrors

”10.04.2021” ”17:56:44” 32.0 4.2 37968895
”10.04.2021” ”18:13:08” 32.0 4.3 38015961
”10.04.2021” ”18:15:10” 32.0 4.3 38015961
”10.04.2021” ”18:30:09” 32.0 4.3 38015961
”10.04.2021” ”18:45:11” 32.0 4.3 38015961
”10.04.2021” ”19:00:09” 32.0 4.3 38015961
”10.04.2021” ”19:15:10” 32.0 4.3 38015961
”10.04.2021” ”19:30:10” 32.0 4.3 38015961
”10.04.2021” ”19:45:11” 32.0 4.3 38015961
”10.04.2021” ”20:00:10” 32.0 4.3 38015961
”10.04.2021” ”20:15:09” 32.0 4.1 38174765
”10.04.2021” ”20:30:09” 32.0 4.2 38197800

EDIT: Das Skript funktionierte noch nicht richtig (Siehe oben die unveränderten Werte bis 20:00) - das Einlesen in eine temporäre Datei funktionierte nur, solange keine Datei gleichen Namens vorhanden war. Im zweiten Anlauf wurde dann die vorhandene temporäre Datei erneut eingelesen. Mit explizitem Löschen der temporären Datei vor dem nächsten Einlesen funktioniert es nun...

Etwa 9000 nicht korrigierbare Fehler pro Stunde, wenn ich mich nicht täusche

 

[MartinP_Do]

Es gibt eine neue Version.
Gibt nun auch die im Messintervall hinzugekommenen uncorrectable codewords und codewords insgesamt aus ...Dafür wird in die Temp-Datei nicht mehr alles hineingeschrieben ...
Datum/Zeit/SNR/Power/Uncorr/deltaUncorr/deltaCodewords

”11.04.2021” ”11:45:06” 32.0 4.3 39080346 15919 186991316
”11.04.2021” ”12:00:06” 32.0 4.5 39099165 18819 186194489
”11.04.2021” ”12:15:06” 32.2 4.3 39115588 16423 183851351

Letzte Zeile:
32.2 dB SNR
4.3 dBmV Power Level
3911558 Unkorrigierte Fehler
16423 unkorr. Fehler sind zwischen 12:00:06 und 12:15:06 hinzugekommen
183851351 Codewords sind zwischen 12:00:06 und 12:15:06 hinzugekommen


EDIT - die bash Arithmetik ist wohl auf 32 Bit beschränkt, die obigen Werte sind inkorrekt, muss das Skript umschreiben - hat jemand Tipps für 64 Bit Arithmetik (bc brachte eine Internet-Recherche zutage)
EDIT2 - scheint doch korrekt zu sein - die Codewords sind ziemlich lang ....
Wenn ich das richtig gelesen habe 12x360 bit, brutto also 4320 Bit/Codeword bei 4096QAM
Da kommt das mit den ca 186 Mio Codewords/15 Minuten (=206666 Codewords/sec) schon zumindest einigermaßen hin

206666*4320 wären ca 900 MBit/s auf den 86 kHz Bandbreite ...

Andersherum gerechnet 12 Bit/Hz * 86MHz Bandbreite = 1032 MBit/s ....

Quelle ...
https://community.cablelabs.com/wik...d?id=d2eb7f4e-5966-4023-99f5-6e44a812abca;1.0

 

[MartinP_Do]

create_rrd.sh konvertiert die von CableLoadMonitor produzierte existierende rrd in eine mit besserer (effizienterer) Datenspeicherung, so dass da bis 1 Jahr drin ist. Die davon produzierte *.rrd wird weiterhin von CableLoadMonitor befüllt - da muss man gar nix dran ändern.

Einen Pferdefuß habe ich gefunden - startet man den CableLoadMonitor NACHDEM create_rrd.sh die Datenbank umgebaut hat, baut der CableLoadMonitor die Datenbank wieder um, bzw sichert die alte, und generiert eine neue ...
Könnte ggfs. an meinen Aufrufparametern liegen.

Muss man ggfs. die entsprechenden checks aus dem CableLoadMonitor ausbauen

Wahrscheinlich reicht es, vorerst nur dies hier auszukommentieren:

 if (renew_rrd_base > 1) { PR("(re)creating the RRD base") if (ex(RRDB_CCMD_NEW, 2, "(.)")) { exit_("rrdtool create fails") }

 

[boba]

Bei mir nicht. Bei mir hat CableLoadMonitor einfach die existierende rrd geschluckt. Man darf nur nicht die Aufrufparameter ändern und auch nicht die cableloadmonitor.cfg, z. b. die Frequenzen. Dann merkt er gar nicht, dass sich was geändert hat.

 

[MartinP_Do]

Gibt es eigentlich eine vernünftige Quelle für das Einlesen in die Bash Skript-Programmierung?
Ich bin da ziemlicher Gelegenheitstäter, und bin da zum Teil doch Überrascht über die Auswirkungen, die nur kleine Änderungen haben ...
Vieles erinnert an C, aber wenn man gewohnheitsgemäß ein Semikolon an das Zeilenende setzt, hat das häufig katastrophale Auswirkungen

 

[boba]

Ich kann dir konkret kein Tutorial nennen - ich habe das seinerzeit noch klassisch aus einem Buch gelernt. Ich bin mir aber sicher, dass du mit google "bash tutorial" eine Menge Info findest.
Aktuell arbeite ich zum einen mit der Referenz ("man bash") und zum anderen, wenn ich ein konkretes Problem bzw. Aufgabe habe und ein Stück Code-Snippet suche, dann google ich nach "bash <Aufgabe>", beispielweise nach "bash array for", wenn ich nochmal sehen will, wie man in bash durch einen Array iteriert. Sehr häufig gibts solche Fragen und auf den Punkt Antworten auf stackoverflow.

Aber bedenke, dass CableLoadMonitor nicht in bash, sondern in awk geschrieben ist. Nur der Wrapper ganz am Anfang und ganz am Ende ist bash. Awk ist weniger eine Sprache zur Ablaufsteuerung, sondern vielmehr eine Sprache zur Textverarbeitung. Das ist eigentlich etwas, was die Text-Ausgabe eines Befehls durchgeht und irgendwas da raus extrahiert. Man kann es verwenden, wenn der Text komplexer ist als das, was man mit einem grep Befehl rausholt, oder wenn man mehrere Werte mit einem Aufruf extrahieren will. Meine Skripte sind bash, aber CableLoadMonitor ist awk. Awk habe ich nie verwendet - bash als Skript, darin grep- und sed-Aufrufe haben immer gereicht. Musste es komplexer werden, habe ich perl verwendet. Awk ist eigentlich nur eine Lösung für Systeme, die alte pre-Bash Shells verwenden und wo es kein perl gibt. Aber bash/perl haben awk obsolet gemacht.

Ich habe nie verstanden, wieso Sparkie awk für das ganze Steuern der Abfragen verwendet. Und dann ist das ganze Skript auch überkompliziert und damit unverständlich und unleserlich. Deshalb versuche ich möglichst nichts darin zu machen (deshalb auch kein upload der Grafik-Generierung auf der github Seite), sondern lieber was davon unabhängiges. Ein Bash-Skript, das die ganzen Aufrufe durchführt und Kanäle plus ggf. multiple Decoder durchläuft, wäre viel direkter, denn bash ist genau dafür gemacht. Für die Verarbeitung der Rückgaben der aufgerufenen Programme kann man dann Text-Prozessoren nach Wunsch nehmen, aber eigentlich sollte ein simples grep genügen, und das wäre dann ein prägnanter Aufruf und kein weiteres Skript im Skript.

Ich schätze, eine simple Schleife in bash zum Durchgehen aller Frequenzen bei 1 Decoder wäre in etwa so groß wie cableload_graph.sh, und nochmal einfacher, weil die Grafikerstellung dor die nicht besonders intuitiven Kommandozeilenparameter für rrdtool graph zusammenbasteln muss.

 

[denunge]

Wenn ich das richtig gelesen habe 12x360 bit, brutto also 4320 Bit/Codeword bei 4096QAM
Da kommt das mit den ca 186 Mio Codewords/15 Minuten (=206666 Codewords/sec) schon zumindest einigermaßen hin

206666*4320 wären ca 900 MBit/s auf den 86 kHz Bandbreite ...

Andersherum gerechnet 12 Bit/Hz * 86MHz Bandbreite = 1032 MBit/s ....

It's difficult to get anything but a ballpark figure. A full codeword is 16200 bits. If it is smaller, it's called a shortened codeword. The CMTS will spit out both full and shortened. Combine that with different modulation profiles...

A guess in the ballpark... 60000-70000 codewords/sec with a loaded 86 MHz channel.

The math... It is 12 bit per subcarrier, not per Hz.

 

[MartinP_Do]

It's difficult to get anything but a ballpark figure. A full codeword is 16200 bits. If it is smaller, it's called a shortened codeword. The CMTS will spit out both full and shortened. Combine that with different modulation profiles...

A guess in the ballpark... 60000-70000 codewords/sec with a loaded 86 MHz channel.

The math... It is 12 bit per subcarrier, not per Hz.

In a 15-minutes-Interval I get 155 .... 195 million codewords (uncorrectable+correctable+unerrored) according to my bash scrip reading from TC4400.
That would give something like 190 000 codewords per second
Here a snippet from my logging:

Date/Time	SNR	Power (dBmV)	Err Codewords	Err Cw (delta)	Rcvd Cw (delta)	Rcvd Cw (end)	Rcvc Cw (start)
”12.04.2021” ”22:45:06”	31.8	4.3	40939302	31189	196080807	5515104813	5319024006
”12.04.2021” ”23:00:06”	32.0	4.2	40970788	31486	196378441	5711483254	5515104813
”12.04.2021” ”23:15:07”	32.2	4.3	41006609	35821	193938095	1610454053	5711483254
”12.04.2021” ”23:30:06”	32.2	4.4	41043748	37139	193557856	1804011909	1610454053

Perhaps Technicolor mean something different according to "codewords"

 

[denunge]

I did a guess on how it may look in a fully loadad channel, with many full codewords. If the traffic pattern is different, with many shortened codewords, it could be very different. There are (tiny) codewords that don't carry user data, but I'm guessing the modem doesn't include those in these numbers.

 

[MartinP_Do]

I did a guess on how it may look in a fully loadad channel, with many full codewords. If the traffic pattern is different, with many shortened codewords, it could be very different. There are (tiny) codewords that don't carry user data, but I'm guessing the modem doesn't include those in these numbers.

My intention is to measure the variation in link quality over the time. I think, the ratio between uncorrectable codewords and transferred codewords is good for that - in a ratio, codeword lenghts are cancelled out....

With RRD i have made my first diagram - 240 uncorrectable codewords max on a million received codewords:
Measuring was not active over the whole time - so there are gaps ...

 

[MartinP_Do]

@boba ich habe die Grafik-Erstell-Skripte in die Crontab eingetragen

- Stündlich die 6 Stunden Grafik aktualisieren
- Alle 6 Stunden die 24-Stunden Grafik aktualisieren
- einmal Täglich die 7-Tage Grafik aktualisieren

Das original-Skript von Sparkie ist so modifiziert, dass es nur noch die Stunden-Grafik nach jedem Tuner-Scan-Durchlauf generiert...

Gelegentlich kommt es vor, dass das Skript beim Ausführen des rrdtool zur Generierung der 7-Tage-Grafik eine Fehlermeldung wirft ("cannot lock database" oder ähnlich)

Muss mich wohl mit dem Abfragen von Fehlerrückgabewerten und einem Retry-Mechanismus beschäftigen ...
Derzeit rufe ich das Skript von Hand auf, wenn ich feststelle dass die Grafik nicht generiert wurde.
Vielleicht es mir nur bei der 7-Tage Grafik aufgefallen, weil sie so selten generiert wird ...

Daneben habe ich bei der Erweiterung des Auswerteskriptes für das TC4400 Modem festgestellt, dass die rrdtools über die Versionen anscheinend keine "kompatiblen" Datenbankformate verwenden ...
Für die Entwicklung habe ich die Skripte erstmal auf einem Linux-PC laufen lassen, und erst als ich zufrieden war nach ein paar Tagen die Sachen auf den Pi1B verschoben ...


Die RRD-Datei des rrdtools 1.7.2 vom Linux-PC schmeckte dem rrdtool 1.7.1 auf dem Raspberry nicht ... habe dann kurzerhand eine neue Datenbank angelegt ... Die verlorenen Daten von den Test-Tagen sind zu verschmerzen ...
Vielleicht liegt es auch daran, dass auf dem Pi die 32-Bit-Version der Tools läuft, und auf dem PC die 64-Bit Version

 

[boba]

Die RRD-Datei des rrdtools 1.7.2 vom Linux-PC schmeckte dem rrdtool 1.7.1 auf dem Raspberry nicht ... habe dann kurzerhand eine neue Datenbank angelegt .

Sowas ist mir auch aufgefallen zwischen 1.4.x und 1.7.x Versionen. Du kannst aber zwischen den Binärformaten konvertieren, indem du nach xml exportierst und dann wieder importierst:

Rechner 1:
rrdtool dump datei.rrd > data.xml

Rechner 2:
rrdtool restore data.xml datei.rrd

 

[MartinP_Do]

Mal schauen, so könnte man ja die alten Daten retten, wenn in den Daten auch Timestamps sind ... sozusagen das, was sich in der pi - RRD angesammelt hat behalten, und die vorher in der PC - RRD angesammelten Daten zerstörungsfrei integrieren ...

 

[boba]

Das geht alles. Der Dump ist eine vollständige ASCII-Repräsentation der rrd Datei inkl. Timestamps. Ist xml Format.

Du musst zunächst alle Daten über export/restore in dasselbe Binärformat überführen.

Dann erstellst du eine neue rrd Datei und fügst in die Erstellungskommandozeile für jede alte rrd Dateien einen -i Parameter dazu, damit dessen Daten bei der Erstellung importiert werden. Reihenfolge und sich überschneidende Datenbereiche sind egal, das regelt rrdtool intern. Das -i gibts ab rrdtool 1.7 oder so.

So habe ich beispielsweise für meine cacti Auswertung eines Tages 15 Jahre Aufhebezeit eingeführt (cacti default: 2) und sämtliche alten Backups und Archive rausgekramt. Cacti läuft hier seit ich bei Unitymedia bin, Mitte 2012. Ich habe die Zeit fast vollständig restauriert bekommen, nur ein halbes Jahr 2015 ist verlorengegangen. Das war ein riesen Aufwand, erst 4 dann 24, dann 31 Kanäle (für jeden Kanal hat cacti ein eigenes rrd), alle mit der Zeit verschieden benannt, außerdem 4 bzw. 5 Uplink Kanäle, und das musste auch noch synchron zur laufenden Auswertung gemerged werden, also innerhalb des 5-Minuten Rasters, in dem cacti die laufenden Daten aktualisiert (frag nicht, wieso das so sein musste, es gab irgendeinen Grund).

 

[__QT__]

EDIT: Meine Probleme auf dem Promox LXC System scheinen wohl mit dem Durchreichen von USB/DVB Hardware zu tun zu haben. Muss ich mich nochwas einlesen/-arbeiten.

Falls jemand einen Panasonic/Xbox USB TV Stick auf nem LXC Proxmox System am Laufen hat, gerne mal mitteilen. Vielleicht findet sich ja mein Fehler noch irgendwo...

 

[__QT__]

Nun hatte ich am WoE nochmal Zeit, mich dem Thema zu widmen und nun läuft es auch. Die Ursache der Probleme waren in der Tat in Bezug auf Gerätedateien durchreichen zum Proxmox LXC unprivilegierten Container und deren Permissions.

Nun hab ich das CableLoadMonitor auf nem Host mit Prometheus, InfluxDB und Grafana laufen. Gibt es denn schon jemand, der die Daten nicht nur via RRD aufzeichnet und PNGs erzeugt, sondern die Daten auch in Grafana visualisiert?

 

[Joerg]

Ja, vgl Beitrag 797.

Jörg

 

[__QT__]

Danke @Joerg, manchmal sieht man den Wald vor lauter Bäumen nicht. Werde mir das mal auf meine Aufgabenliste schreiben, mich mit Telegraf zu beschäftigen. Schade, dass es nicht auch schon gleich mit Prometheus oder so geht. Aber auch kein Hindernis

Erstmal bin ich froh, dass das Auslesen auch im virtualisierten Container nun klappt. Zugriff auf die Hardwaregerätedateien war hier die Hürde, die man nehmen muss...

 

[__QT__]

Ich schon wieder. Leider bin ich noch nicht ganz happy mit dem Auslesen. Es wird für meinen Geschmack zu oft der Wert "0" ermittelt. Woran könnte sowas liegen? Sieht dann auch dementsprechend "leer" im PNG Graph aus. Siehe Bild.

DVB-C tuner(s) found: 1, using thereof: 1
16:06:36: 0 33088 27072 1504 1504 0 1504 1504 0 39104 0 22560 3008 37600 0 0 37600 0 0 9024 0 0 7520 1504 224096
16:07:31: 0 0 0 18048 24064 36096 4512 1504 0 6016 36096 9024 0 1504 10528 3008 0 1504 1504 36096 34592 1504 34592 31584 291776

 

[why_]

Bei mir lag es am durchreichen des USB-Controllers an die VM, das lief einfach nicht sauber, ich hab dann als Ausweg das ganze auf dem Proxmox host selbst laufen lassen und so funktioniert das einwandfrei. Ziemlich schade aber ich hab keine andere Lösung gefunden.