Unitymedia Auslastung des eigenen Segments ansehen (reloaded)

[srxx]

Hier ist scheinbar auch recht wenig los

 

[rv112]

Cool, da ist wirklich wenig los. Bei mir ist es teils doch recht voll am Abend, das war gefühlt bis vor einigen Monaten nicht so. Aber da habe ich auch nicht gemessen...

 

[sparkie]

regelrecht viel ist auch bei mir nicht los (noch DOCSIS 3.0). Woher soll die Last auch kommen? Es tummeln sich die vielen uralten Modems hauptsaechlich auf den untersten 8 Frequenzen. Zu erkennen an den angehobenen roten Linien

 

[Holzlenkrad]

Ach jetzt verstehe ich auch den Sinn hinter der Aufteilung der Downstream-Kanäle in zwei verschiedene Farben.
Aber in deinem Segment ist echt nichts los. Selbst ein Kunde mit einem 150MBit Vertrag sollte da schon deutlich mehr Traffic-Spitzen verursachen...
Kannst du vielleicht noch bei zwei Feature-Wünschen überlegen, ob die umsetzbar wären? Zum einen dauert das Berechnen der Graphen auf dem Pi schon eine relevante Zeit, vielleicht reicht es die Graphen für 7 Tage und mehr nur einmal pro Stunde zu berechnen und nicht jede Minute einmal?
Und das Logging optional zu machen? Bei mir kommen da pro Stunde über 100 MB zusammen, ich habe zwar genügend SD-Karten, aber das Aufsetzen dauert ja auch immer etwas..

@rv112
Wie sieht es bei dir aus? Nutzt du wieder beide Tuner? Bei mir ist der Stick mit einem Sleep von 0.3 Sekunden (immernoch deutlich unter 1min pro Durchgang!) nach dem Einstellen der Frequenz nicht mehr abgestürzt.
Allerdings suche ich noch nach einer Methode den Stick ohne manuelles Abstecken in dem Fall wieder zum Leben zu bringen. Aktuell teste ich ob es reicht einfach für ein paar Sekunden den USB-Hub im Raspberry Pi stromlos zu schalten.

 

[rv112]

Ich nutz beide Tuner mit 0.5. Läuft stabil bisher!

 

[sparkie]

Kannst du vielleicht noch bei zwei Feature-Wünschen überlegen, ob die umsetzbar wären? Zum einen dauert das Berechnen der Graphen auf dem Pi schon eine relevante Zeit, vielleicht reicht es die Graphen für 7 Tage und mehr nur einmal pro Stunde zu berechnen und nicht jede Minute einmal?
Und das Logging optional zu machen? Bei mir kommen da pro Stunde über 100 MB zusammen, ich habe zwar genügend SD-Karten, aber das Aufsetzen dauert ja auch immer etwas..

klar, macht SInn. Die Logfiles werden allerdings bereits jetzt rotiert. Es gibt also schon eine gewisse Obergrenze (ca. 15MB) fuer den fuer's Logging benoetigten Speicherplatz.

Die Punkte habe ich in die ToDo Liste aufgenommen Mir sind derzeit aber etwas die Haende gebunden, die Umsetzung ist etwa in der ersten Dezemberhaelfte...

 

[MartinP_Do]

regelrecht viel ist auch bei mir nicht los (noch DOCSIS 3.0). Woher soll die Last auch kommen? Es tummeln sich die vielen uralten Modems hauptsaechlich auf den untersten 8 Frequenzen. Zu erkennen an den angehobenen roten Linien

Da ist mein Segment deutlich voller ... gestern Abend bis zu 1 GBit/s .... das sind 83 % Auslastung der 24 ausgewerteten Kanäle ... viel "Luft nach oben" für einen "Wochenendzuschlag" bei der Last ist da nicht mehr ;-)

 

[rv112]

Ich bin Abends regelmäßig bei 1,3 GBits.

 

[MartinP_Do]

Ich bin Abends regelmäßig bei 1,3 GBits.

Du misst ja auch 31 Kanäle

1300 MBit/s/ (31*50MBit/s) = 83 %

Ich messe immer noch nur 24 Kanäle

1000 Mbit/s/(24*50MBit/s) = 83 %

;-)


Nachtrag: Wenn ich die Kanäle um die bekannten Frequenzen 474:482:490:498:522:530:538 ergänzen wollte, müsste ich ja den Prozess stoppen - überlebt die Datenbank das, oder sind die angesammelten Messwerte der Vergangenheit verloren bzw. dann aufgrund der geänderten Anzahl von Messwerten unbrauchbar?

 

[rv112]

Kannst stoppen keine Sorge.

 

[sparkie]

Nachtrag: Wenn ich die Kanäle um die bekannten Frequenzen 474:482:490:498:522:530:538 ergänzen wollte, müsste ich ja den Prozess stoppen - überlebt die Datenbank das, oder sind die angesammelten Messwerte der Vergangenheit verloren bzw. dann aufgrund der geänderten Anzahl von Messwerten unbrauchbar?

wenn geaenderte und inkompatible Optionen beim Aufruf die Erzeugung einer neuen Datenbasis erfordern, dann sollte vom Programm vorher automatisch die alte Datenbasis (*.rrd File) + zugehoerige Konfiguration (*.cfg File) weggespeichert werden. Bei Bedarf kann man beides (bei gestopptem Prozess) wieder zurueckkopieren. Und hat dann den alten Zustand wieder.

eine geaenderte Zahl von Messwerten erfordert eine neue rrd-Datenbasis.

 

[MartinP_Do]

Ich bin da noch etwas unschlüssig - je nachdem, was man wissen will, ist die Information beschränkt auf die 24 Kanäle, die die Fritzbox belegt, oder die über die Gesamt-Belastung des Segments interessanter...
Natürlich kann man, wenn man die vollständigen 31-Kanal-Messwerte in der Datenbank hat, auch Auswertungen machen, die nur eine Untermenge von Kanälen betreffen - von da her werde ich wohl doch die volle Breite abholen lassen - dann sind die Rohwerte zumindest komplett ...

Kommt es eigentlich vor, dass ein DOCSIS 3.0 Kabel-Router im laufenden-Betrieb vom CMTS einen anderen Set von Kanälen zugewiesen bekommt, oder steht der Set bis zum nächsten Router-Reboot?

 

[MartinP_Do]

Übrigens ..... ein wenig Suche bringt folgendes bzgl. DOCSIS 3.1 Analyse zu Tage:

https://ieeexplore.ieee.org/document/7684733

Habe da aber die Befürchtung, dass der allseits beliebte "RTL-Stick" da überfordert ist ...

http://www.do2phs.de/index.php/projekte/22-beta-bandbeobachtung-mit-rtl-sdr-sticks

 

[Andreas1969]

Kommt es eigentlich vor, dass ein DOCSIS 3.0 Kabel-Router im laufenden-Betrieb vom CMTS einen anderen Set von Kanälen zugewiesen bekomm

Die ollen Casa's können das

 

[rv112]

Ist technisch kein Problem, aber habe ich bei Unitymedia noch nicht gesehen.

 

[rv112]

Hier lief nun alles gut, bis ich eben einen Speedtest gemacht habe (weiß nicht ob es damit was zu tun hat). Seitdem ist Kanal 746 jedoch sehr niedrig mit der Last, was ich glaub ein Anzeigefehler ist und das Programm auch kurz mit Fehler abgestürzt.

EDIT: ja, sobald ich einen Speedtest mache und der Kanal 746 durchläuft, kommt es zu diesem Fehler. Außerdem bringt ein dvbtune noch folgenden Fehler:

pi@raspberry3:~ $ dvbtune -c 0 -f 746000000 -s 6952 -qam 256 -m
Using DVB card "Silicon Labs Si2168"
tuning DVB-C to 746000000, srate=6952000
polling....
Getting frontend event
FE_STATUS:
polling....
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_CARRIER
polling....
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
Bit error rate: 0
Signal strength: 0
SNR: 0
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
FE READ_BER: : Unknown error 524
FE READ SIGNAL STRENGTH: : Unknown error 524
FE READ_SNR: : Unknown error 524
FE READ UNCORRECTED BLOCKS: : Unknown error 524
Signal=0, Verror=0, SNR=0dB, BlockErrors=0, (S|C|)
FE READ_BER: : Unknown error 524
FE READ SIGNAL STRENGTH: : Unknown error 524

 

[sparkie]

das Programm ist nicht abgestuerzt sondern stellt vielmehr fest, dass fuer die Frequenz 746MHz der dvbsnoop keinen Messwert (mehr) liefert.

In Folge dessen versucht es (per default) den Sundtek DVB Treiber neu zu starten. An dieser Stelle muesste jetzt natuerlich der Code stehen, der die entsprechend verwendete Hardware neu initialisiert.

Bei einem Sundtek auf einem RPI der ersten Stunde kommt es oefter mal vor, dass sich die Treiber verhaengen. Der automatische Neustart hilft hier aber zuverlaessig.

Was bei deiner speziellen Hardware hier evtl. fuer die Recovery gemacht werden muss kann ich leider nicht sagen.

 

[rv112]

Ich habe den RPi manuell neu gestartet, damit geht es nun wieder.

 

[sparkie]

wenn der dvbsnoop im Treiber haengt, dann hilft im Moment leider nur noch das

 

[rv112]

Hier mal was Freitags bei mir los ist.

 

[MartinP_Do]

Bei mir auch - alle Kanäle, die ich messe haben in dem Stunden-Plot um die 45 MBit/s maximal und letzte Werte über 35 MBit/s ...

 

[sch4kal]

ich wuerde es einfach in 'systemd' integrieren. Im Github befinden sich hierzu 2 Files:

https://raw.githubusercontent.com/sp4rkie/docsis-cable-load-monitor/master/cableloadmonitor
https://raw.githubusercontent.com/sp4rkie/docsis-cable-load-monitor/master/cableloadmonitord.service

das erstere z.B. ins /root/bin Verzeichnis schieben und ausfuehrbar machen. Zeile mit 'CMD = "/root/bin/CableLoadMonitor -d 1 -i..."' anpassen.
das zweitere ins '/etc/systemd/system' Verzeichnis schieben. Zeile mit 'ExecStart=/root/bin/cableloadmonitor' anpassen.

Service aktivieren und starten

systemctl enable cableloadmonitord
systemctl start cableloadmonitord

man muss nur aufpassen, dass keine 2 Prozesse gleichzeitig laufen. Das wird leider vom Programm noch nicht abgefangen. D.h. wenn du manuell was ausprobieren willst muss immer erst der systemd-Prozess gestoppt werden:

systemctl stop cableloadmonitord

wenn der Service nicht automatisch nach reboot gestartet werden soll, braucht er natuerlich nicht aktiviert zu werden:

systemctl disable cableloadmonitord

Fehlt afaik noch ein

systemctl daemon-reload

vor dem Starten ^^

 

[Holzlenkrad]

wenn der dvbsnoop im Treiber haengt, dann hilft im Moment leider nur noch das

Wenn der Scanner im Autostart ist, dann könnte man den Pi zumindest automatisch neu starten

 

[rv112]

Ja das wäre wohl gut. Bei mir hängt alles im Autostart.

 

[sparkie]

Fehlt afaik noch ein

systemctl daemon-reload

vor dem Starten ^^

wenn man es nur so hinschreibt ohne zu testen, dann fehlt immer was
danke, ich werde das jedenfalls in der Kurzanleitung im github entsprechend beruecksichtigen

Wenn der Scanner im Autostart ist, dann könnte man den Pi zumindest automatisch neu starten

ist schon auf der ToDo Liste. Der RPi-eigene Watchdog ist ja wie geschaffen fuer sowas