• Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
    Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Auslastung des eigenen Segments ansehen (reloaded)

Diskutiere Auslastung des eigenen Segments ansehen (reloaded) im Internet und Telefon über das TV-Kabelnetz Forum im Bereich Internet und Telefon bei Unitymedia; Jetzt funktioniert es auch mit 4 Sticks: [email protected]:~# ./CableLoadMonitor -v -sequential -t /data/ -f...

no sleep

Beiträge
15
Reaktionen
4
Jetzt funktioniert es auch mit 4 Sticks:
Code:
[email protected]:~# ./CableLoadMonitor -v -sequential -t /data/ -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
evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 31 ]
474/QAM256 482/QAM256 490/QAM256 498/QAM256 522/QAM256 530/QAM256 538/QAM256
546/QAM256 554/QAM256 562/QAM256 570/QAM256 578/QAM256 586/QAM256 594/QAM256
602/QAM256 618/QAM256 626/QAM256 634/QAM256 642/QAM256 650/QAM256 658/QAM256
666/QAM256 674/QAM256 682/QAM256 690/QAM256 698/QAM256 706/QAM256 746/QAM256
754/QAM256 762/QAM256 770/QAM256
graph display mode: standard
graph destination dir: /data/
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
using multiple DVB-C tuners: sequentially (if applicable)
DVB-C failure recovery method: retry
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
no Sundtek card(s) found, trying others (unsupported)
DVB-C tuner(s) found: 4, using thereof: 4
20:35:42: 15559 14077 19901 15762 16855 15735 18488 16240 15760 16370 20356 13043 14177 19863 17493 19144 20642 19974 18219 16778 15753 24560 22796 20210 17712 22645 14411 14503 16069 16657 19606 549358
20:37:17: 17301 18882 17950 17983 21284 16269 18836 21414 20002 15492 23419 14371 17723 15701 15199 13580 21314 19511 14980 19135 18883 18751 19429 16541 21272 20522 15295 22194 13488 17324 20598 564643
20:38:32: 17850 22035 19510 18313 19972 15793 15670 14417 12363 15962 12612 17069 17724 17613 13879 14061 15122 15495 13890 18382 11109 15943 14969 18402 13964 19625 16334 14892 15042 15750 14847 498609
20:39:47: 13011 16671 13040 14842 25650 17871 15829 11692 16238 10759 12838 14574 12624 16521 11650 16762 11663 12094 12962 12693 14733 14367 12573 14865 14893 15477 11707 16502 12575 10783 11705 440164
20:41:02: 15320 14280 14118 16331 14233 16007 12733 10833 14321 15327 19103 12931 10206 13852 12961 15291 9527 15740 13432 12841 17593 11006 13417 16145 17285 15698 14374 15250 10254 17381 14831 442621
20:42:35: 14013 14065 14106 14670 10811 16892 13429 15333 14012 13436 12362 14881 16264 11944 11912 19687 13005 14981 11950 13267 13010 14488 11634 11534 17340 16866 12304 12439 13556 13958 10516 428665
20:43:50: 13415 12459 12725 15524 11046 14046 14292 13943 10616 14079 15780 11171 10582 15784 10407 14833 12875 12271 12419 11242 11644 13415 14777 14740 13059 11046 10601 18678 14171 15161 14064 410865
20:45:05: 17005 10433 15922 19670 13498 17002 13545 14428 15426 14737 13634 14367 14972 12637 11142 14800 14076 14999 12706 17866 16149 11893 12944 12903 11481 13999 11328 12180 13837 14469 14263 438311
20:46:20: 16721 14529 16839 13076 17386 13284 13831 24566 12758 14936 16586 13498 12147 13454 16579 13905 19753 15713 15475 14233 14973 18876 14023 14435 16783 19815 16014 16559 17037 14800 17278 489862
20:47:52: 16373 15414 14759 16221 17560 12955 17247 11670 15064 19362 16384 17486 18809 14478 18496 17510 23282 20861 18718 20911 16677 18542 15419 17785 18363 15536 13630 17134 16745 16304 14803 524498
20:49:07: 14061 22492 17537 12652 13867 17901 21392 20666 16011 15509 17383 19100 17504 14148 17088 15103 15983 16907 16131 17064 12948 20410 14356 15896 15761 16069 16787 14069 12152 13226 12371 502544
20:50:22: 16827 16609 15347 17322 16316 15970 15229 17245 14076 17900 18074 14952 25647 23266 19151 18145 19859 20154 16116 21947 17755 23190 14963 18848 15179 18115 16186 14464 15905 14398 15945 545100
20:51:37: 19691 16904 18743 14874 17392 21611 12872 14837 19440 16343 18360 22549 24406 21427 15408 24143 15200 14942 16008 14654 16744 16720 23356 21144 13664 18830 19841 17053 20287 21639 18571 567653
An den Timestamps kann man schön sehen, mit welchem Tempo er über die 31 Kanäle rennt.

Physikalisch sieht das so aus:
IMG_2091.jpg
 

sparkie

Beiträge
787
Reaktionen
51
Aufbau schaut gut aus 👍
aber Ziel waere es, die 'sequential' Option am Ende wieder herauszunehmen zu koennen, damit die Messung auf allen 4 Sticks parallel durchgefuehrt wird. Dann sollte 1 Komplettscan fast 4x so schnell durchlaufen als jetzt.

Der Pi 4 kann mit einem 3A Netzteil insgesamt 1.2A an den USB Ports liefern: Power Supply - Raspberry Pi Documentation.

Das sollte doch fuer die 4 Sticks reichen um den Hub einzusparen zu koennen?

Wenn es Probleme gibt am besten zusaetzlich mit '-v' Option starten und schauen was dann im 'CableLoadMonitor.log' und den '/var/log/messages' steht.
 
Zuletzt bearbeitet:

no sleep

Beiträge
15
Reaktionen
4
Danke und du hast recht! Es funktioniert auch ohne "-sequential", wenn die Stromversorgung der Sticks gesichert ist! Bei 3 Sticks ohne separaten Hub war das wohl nötig, um beim Tunen die Last auf das Netzteil zu verteilen. Mit 4 Sticks und Netzteil ohne "-sequential" läuft ein Scan über 31 Kanäle in exakt 21 Sekunden durch. :cool:
Ohne Netzteil wirft der Pi die Sticks raus, sobald man den Scan startet:
Code:
Jul 19 07:41:05 raspberrypi kernel: [ 318.030325] mn88472 7-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw'
Jul 19 07:41:05 raspberrypi kernel: [ 318.223004] mn88472 8-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw'
Jul 19 07:41:05 raspberrypi kernel: [ 318.423060] mn88472 9-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw'
Jul 19 07:41:05 raspberrypi kernel: [ 318.622510] mn88472 10-0018: downloading firmware from file 'dvb-demod-mn88472-02.fw'
Jul 19 07:41:06 raspberrypi kernel: [ 318.808936] usb usb2-port1: over-current change #1
Jul 19 07:41:06 raspberrypi kernel: [ 319.051733] usb usb2-port2: over-current change #1
Jul 19 07:41:06 raspberrypi kernel: [ 319.245821] usb 1-1.1: USB disconnect, device number 10
Jul 19 07:41:06 raspberrypi kernel: [ 319.291759] usb usb2-port3: over-current change #1
Jul 19 07:41:06 raspberrypi kernel: [ 319.531702] usb usb2-port4: over-current change #1
Jul 19 07:41:06 raspberrypi kernel: [ 319.771794] usb usb2-port1: over-current change #2
Aber damit kann ich persönlich leben.
 

no sleep

Beiträge
15
Reaktionen
4
Nach der ganzen Spielerei mit dem RPI und den Xbox Tunern habe ich jetzt mal die "High-End Version" auf einem komplett anderen System ausprobiert:
Code:
DVB-C tuner(s) found: 8, using thereof: 8
08:49:01: 16632 15806 15763 15526 14878 18708 14924 14985 12660 18018 14938 17746 17157 18164 17469 13274 16976 16297 16137 16683 16532 16578 17621 17182 11234 11264 11074 11245 10986 11250 11579 469286
08:49:07: 17551 20071 19737 15514 17625 17432 16805 15818 13551 16115 13690 16979 16356 14560 13609 12519 20437 16750 17510 18675 16495 17740 16880 17059 13460 16109 13896 12973 13785 12843 12316 494860
08:49:13: 17105 14369 16726 16050 14328 16427 14408 13957 9396 16054 9346 13734 14094 15916 12421 10197 13893 14419 13252 13931 12407 12468 12742 12635 12826 13077 12336 12734 13295 11962 13390 419895
08:49:19: 11164 16053 10653 11210 10951 14430 13205 12104 11582 15803 11533 15199 14398 14437 15110 11611 13968 12529 13898 11924 13576 12857 11529 12116 10890 10653 11605 10261 9460 9756 9605 384070
08:49:25: 16048 22618 13897 15507 15313 13097 16079 14498 10235 15162 10357 16933 14454 13771 14609 13329 14203 14540 13086 14055 13551 13422 14430 12983 11066 10780 11185 10565 11170 10112 10653 421708
08:49:31: 17844 17156 20553 18687 16677 18238 16318 17150 8432 10832 7540 9221 11233 12723 10761 9454 8394 8708 9225 9840 9347 8498 8245 8435 8551 6895 7162 6956 7779 7178 7450 345482
08:49:37: 7117 6533 6373 7255 6832 6548 6757 7247 11073 9474 9744 11342 11424 10267 10969 9697 10551 10466 10382 10737 10847 9498 11106 9135 7079 7200 6609 7125 7043 6911 6658 269999
08:49:43: 5102 5655 5118 6622 5728 5339 4861 5365 3914 3977 3815 4370 4062 4129 3925 4237 6008 6350 6120 6471 6414 6321 6214 7393 6860 6622 6861 6754 6810 6517 6935 174869
08:49:49: 6733 6306 7744 7166 7113 7184 6792 7058 5987 5949 5859 5610 5441 6248 5598 5766 7305 6968 7264 7383 7064 7247 6907 6852 6378 6583 6590 6673 6905 6635 6658 205966
08:49:55: 8293 8601 8170 8069 7845 8434 19404 7395 7479 7195 7474 7023 7389 8085 7372 7371 5542 5156 5417 7140 4984 5897 5687 5374 4140 4120 4285 4218 4202 4131 4266 210158
08:50:01: 10574 10745 10005 12721 10351 10798 10170 10356 7872 10343 7840 8153 10130 7944 10676 8815 6416 6147 5870 5928 5723 5880 5758 5947 7669 8078 7772 7831 7602 8040 7514 259668
10 Durchläufe pro Minute mit einer Digital Devices Max A8i.👌
https://digitaldevices.de/produkte/dvb-komponenten/max-a8/

Mein 'dvbtune' benötigte allerdings einen kleinen Patch, um mit 8 Frontends umzugehen.
 

sparkie

Beiträge
787
Reaktionen
51
Cool, einen Scan von 31 Kanaelen in 6 Sekunden. Damit ist dir der Platz 1 in der CLM Hall of Fame bis auf weiteres sicher 🏆
 
  • Gefällt mir
Reaktionen: no sleep
boba

boba

Beiträge
1.058
Reaktionen
214
Ich scheine es mit dem xbox Tuner zum laufen gebracht zu haben. Vielen Dank für den Tipp!
Die Durchschnitts-Auslastung meines Segments scheint jetzt im Moment so um die 600 mbit zu sein. Auf meinem schon etwas betagten Raspberry Pi 2 dauert ein Scan (31 Kanäle) mit dem einen Tuner um die 90 Sekunden.

Etwas gedauert hat es, bis ich rausgefunden habe, dass für den xbox Tuner noch ein Firmware File namens dvb-demod-mn88472-02.fw fehlt. Ich verwende Centos 7 auf meinem pi, da ist das nicht dabei. Vielleicht unter dem Standard Raspian, wenn das sonst keiner bemerkt hat. Die Datei gibts bei http://palosaari.fi/linux/v4l-dvb/firmware/MN88472/02/latest/dvb-demod-mn88472-02.fw liegt auch in einem armbian github Repository:
https://github.com/armbian/firmware/blob/master/dvb-demod-mn88472-02.fw

Damit das unter Centos 7 geht, musste ich den Source zu dvbtune und dvbsnoop finden und selbst kompilieren. Das Tool dvb-fe-tool gibts im Paket v4l-utils.

Tja, hübsche Bastelei. Ich werde das CableLoadMonitor Skript "ausschlachten" und ein php Modul für mein cacti Monitoring neu machen.
Die dvb Tools dvbtune und dvbsnoop sind uralt, möglicherweise ist ja eines der Tools aus v4l-utils eine Ablösung. Mal schauen.

Das ganze kommt gerade recht, um mit der Einführung des ofdm Kanals für Docsis 3.1 obsolet, oder aber zumindest unvollständig zu werden ;)

Im CableLoadMonitor habe ich einen kleinen Fehler gefunden, und zwar wenn dvb-fe-tool verwendet wird, um zu zählen wieviele Tuner vorhanden sind, dann erkennt er die Zahl nicht und nimmt 20. Mein dvb-fe-tool liefert 255 als return code und nicht -1 bei Fehler:
Bash:
[[email protected] dvb]# dvb-fe-tool -a 0 -d DVBC/ANNEX_A
INFO Device Panasonic MN88472 (/dev/dvb/adapter0/frontend0) capabilities:
INFO CAN_2G_MODULATION
INFO CAN_FEC_1_2
INFO CAN_FEC_2_3
INFO CAN_FEC_3_4
INFO CAN_FEC_5_6
INFO CAN_FEC_7_8
INFO CAN_FEC_AUTO
INFO CAN_GUARD_INTERVAL_AUTO
INFO CAN_HIERARCHY_AUTO
INFO CAN_INVERSION_AUTO
INFO CAN_MULTISTREAM
INFO CAN_MUTE_TS
INFO CAN_QAM_16
INFO CAN_QAM_32
INFO CAN_QAM_64
INFO CAN_QAM_128
INFO CAN_QAM_256
INFO CAN_QAM_AUTO
INFO CAN_QPSK
INFO CAN_TRANSMISSION_MODE_AUTO
INFO DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
INFO Supported delivery systems:
INFO DVBT
INFO DVBT2
INFO [DVBC/ANNEX_A]
[[email protected] dvb]# echo $?
0
[[email protected] dvb]# dvb-fe-tool -a 1 -d DVBC/ANNEX_A
ERROR No such file or directory while opening /dev/dvb/adapter1/frontend0
[[email protected] dvb]# echo $?
255
 

millen

Beiträge
166
Reaktionen
27
Ich scheine es mit dem xbox Tuner zum laufen gebracht zu haben. Vielen Dank für den Tipp!

Etwas gedauert hat es, bis ich rausgefunden habe, dass für den xbox Tuner noch ein Firmware File namens dvb-demod-mn88472-02.fw fehlt. Ich verwende Centos 7 auf meinem pi, da ist das nicht dabei.
Heute kam meiner ebenfalls und ich habe ihn auch seit ca. einer Stunde am laufen, ich habe wahrscheinlich genauso lange gebraucht wie du, um das mit der Firmware zu merken 😅

Bei uns hier ist die Auslastung aktuell bei ca. 500 Mbit/s.
 
Soldierofoc

Soldierofoc

Beiträge
615
Reaktionen
28
2,4Gbit ist die maximale Kapazität, oder?

Habe heute einen zweiten Xbox One Stick bestellt und etwas Zubehör, damit der Scan etwas flotter läuft.
 

no sleep

Beiträge
15
Reaktionen
4
Mit dem Link zu dem Xbox Tuner habe ich ja etwas angestellt...😜
Freut mich, daß es bei euch auch so rund läuft!
 
Soldierofoc

Soldierofoc

Beiträge
615
Reaktionen
28
Allerdings :). War ein top Tipp und für 13€ wirklich sehr attraktiv!
 
boba

boba

Beiträge
1.058
Reaktionen
214
Hier hat jemand dasselbe gemacht, nur in python, ohne externe Tools (er hat die dvb ioctl's in python gemacht), zum Befüllen einer Datenbank über carbon und Visualisierung mit Grafana:
https://www.incertum.net/post/2019/pydtm_1/

Wenn ich seine grafana Demo so sehe, dann habe ich wohl die Ablösung für mein cacti gefunden, die ich als nächstes Hobby-Projekt in Angriff nehmen werde.

@no sleep auf alle Fälle, und vielen Dank für die Erneuerung des Interesses an diesem Thema. Ich hoffe, Microsoft zahlt dir Prozente für die plötzlich in den Himmel schießende Nachfrage.
 

sparkie

Beiträge
787
Reaktionen
51
Im CableLoadMonitor habe ich einen kleinen Fehler gefunden, und zwar wenn dvb-fe-tool verwendet wird, um zu zählen wieviele Tuner vorhanden sind, dann erkennt er die Zahl nicht und nimmt 20. Mein dvb-fe-tool liefert 255 als return code und nicht -1 bei Fehler:

danke fuer den Hinweis. Das Problem liegt aber in der speziellen Version deines 'dvb-fe-tool'. Der Return-Code wird in meinem Script eh nicht ausgewertet sondern nur die Fehlerausgabe. Und die lautet bei dir 'ERROR No such file or directory' statt 'WARNING device dvb1.frontendx not found'. Der Fehler tritt auf der beschriebenen Raspberry Installation nicht auf. Aber ich werde deinen Fall natuerlich auch noch beruecksichtigen. Ist schon auf der ToDo Liste :)


@no sleep auf alle Fälle, und vielen Dank für die Erneuerung des Interesses an diesem Thema. Ich hoffe, Microsoft zahlt dir Prozente für die plötzlich in den Himmel schießende Nachfrage.

die Folge wird schon eher sein, dass der Preis fuer den Xbox Tuner bald in die Hoehe schiesst :)

Das war einst bei der Seagate Dockstar genauso, als sich herausgestellt hat, dass sich die gut als DVB Server Plattform einsetzen laesst.
 
Zuletzt bearbeitet:
boba

boba

Beiträge
1.058
Reaktionen
214
@sparkie Ich hätte noch einen Kommentar zu deiner Verwendung von rrdtool. Bitte nicht als Klugscheisserei ansehen, sondern als sachliche Anmerkung.

Also du hast die Konzepte, die hinter rrdtool stehen, nicht so umgesetzt wie man das tun sollte bzw. wie es gedacht ist. Ich versuche mal zu erläutern, wie es gedacht ist eine *.rrd Datei zu erstellen und zu füttern.

Generelles Prinzip aller Messungen: man führt regelmäßig Messungen aus und erhält Werte. Man führt diese Messungen in möglichst festen und gleichen Zeitabständen durch und erhält (Zeit, Wert) Paare. Allerdings ist es in der Realität so, dass Zeitabstände nie ganz gleichmäßig sind, und manchmal fallen auch einzelne Messungen aus.

Der rrdtool Ansatz ist dazu:
Man definiert ein Zeitraster, in dem man gedenkt die Messwerte einzuliefern. In rrdtool Terminologie ist das der step, und er wird in Sekunden angegeben. Der Step unterteilt die Zeit in Intervalle. Hat man einen Step von 300 Sekunden, dann sind die ersten 300 Sekunden ein Intervall, die nächsten 300 Sekunden das nächste Intervall und so weiter.
Alle Datenwerte, die innerhalb eines Intervalls an rrdtool geliefert werden, werden auf den Anfangszeitpunkt des kommenden Intervalls konsolidiert. Ist das Intervall abgelaufen, wird der Mittelwert der gelieferten Datenwerte "primary data point" (pdp) genannt und in der Datenbank abgespeichert. Somit erhält die Datenbank normierte Werte, die so aussehen, als wären sie alle in einem absolut exakten Zeitraster generiert worden, egal wie ungenau das Zeitraster bei der Messung tatsächlich war. So kann man später daraus Grafiken mit exakten Intervallen erstellen.

Abgespeichert werden die primary data points (pdp) in sogenannten round robin archives (rra). Für jedes rra definiert man, wieviele pdp's zu einem in der Datenbank gespeicherten Wert zusammengefasst (aggregiert) werden sollen, und wieviele Punkte abgespeichert werden sollen (ältere Punkte werden automatisch gelöscht, deshalb "round robin").

Die Idee ist, dass man die Daten in mehreren rra's dupliziert abspeichert, mit jeweils unterschiedlicher Aggregierung (Konsolidierung). Die pdp's direkt speichert man z.B. für eine Woche, eine Konsolidierung auf eine halbe Stunde speichert man für einen Monat, die Konsolidierung auf eine Stunde 2 Monate, die Konsolidierung auf einen Tag 1 Jahr. Das spart Speicherplatz und geht davon aus, dass man von älteren Daten nicht mehr die höchste Auflösung benötigt, sondern nur noch einen konsolidierten Überblick. Heutzutage bei praktisch unbegrenztem Speicherplatz nicht mehr ganz zeitgemäß, aber so ist erstmal das Design.

Du hast jetzt mit -s 1 einen Step von 1 angegeben, d. h. jede Sekunde wird ein pdp generiert.
Dann hast du bei den DS Definitionen einen Heartbeat von 120 angegeben. Das bedeutet, es wird für 120 Sekunden der vorherige Wert als pdp übernommen, wenn kein neuer reinkommt.
Mit RRA:AVERAGE:0.1:10:60480 speicherst du einen rra mit der Konsolidierung 10 pdp's, der 60480 Punkte enthält, d.h. den Zeitraum 1s * 10 * 60480 = 604800s (7 Tage) umfasst, und die Konsolidierungsfunktion is AVERAGE, d. h. der Mittelwert der pdp's.

So isses nicht ganz gedacht.
Du gibst einen step von 1 vor, d.h. dein rrdtool erwartet jede Sekunde einen neuen Messwert. Bei einem Tuner und 31 Kanälen purzelt bei mir in etwa alle 80-90 Sekunden eine Messung heraus. Also hätte man nur jeden 80ten pdp mit Messwert und alle anderen Werte wären UNKNOWN. Damit das jedoch nicht passiert, sondern die Datenbank so lange mit den alten Werten befüllt wird, bis ein neuer Wert kommt, hast du einen heartbeat von 120 angegeben, d.h. bis zu 120 Sekunden lang wird nicht UNKNOWN eingetragen, wenn kein Wert kommt, sondern der vorherige Wert kopiert.
Dann gibts da noch die ominöse 0.1 bei dir in der RRA Definition, das ist der xff oder "xfiles factor". Der bestimmt, wieviele der zu konsolidierenden Werte tatsächliche Werte enthalten müssen und nicht UNKNOWN sein dürfen. Wenn nämlich zuviele Werte fehlen, dann wäre die Konsolidierung ungenau und man kann nicht konsolidieren - der konsolidierte Werte müsste dann auch UNKNOWN sein. Mit 0.1 bei 10 Werten gehst du auf Nummer sicher, damit auch ja ein Wert gespeichert wird, auch wenn es der einzige in dem Intervall ist. Und das kann dann auch durchaus ein kopierter Wert von vorher sein wegen des Heartbeat 120 und kein originaler. Damit werden die Daten recht ungenau und verschmiert.

Die Folge ist zum einen, dass lauter Kopien von alten Datenpunkten in der Datenbank liegen statt UNKNOWN. Und die Genauigkeit ist auch nicht so wahnsinnig hoch, wenn man alte Werte mehrere Minuten lang mitschleppt. Es macht keinen Sinn, mit einer Genauigkeit von 10 Sekunden abzuspeichern, wenn die Daten tatsächlich nur eine Genauigkeit von 120 Sekunden haben.

Best practice für heartbeat ist step*2, d.h. es soll mal ein Datenpunkt ausfallen dürfen, aber wenn mehr ausfallen, dann kann man auch nichts in der Datenbank abspeichern.
Best practice für xff ist 0.5, d.h. wenigstens die Hälfte in einem Konsolidierungsintervall sollte an Datenpunkten vorhanden sein, sonst kann man nicht konsolidieren - es sind schlicht zu wenig Daten vorhanden.
Heartbeat und xff mit anderen Werten, auch extremen Werten wie den deinen, machen Sinn für bestimmte Typen von Datensammlungen, z.B. freier Festplattenplatz, der sich nur ganz behäbig verändert. Für Durchsatzmessungen wie den hier jedoch nicht.

tl;dr
Am Anfang muss die Überlegung stehen, welches Intervall man möchte. Bei einem Tuner auf einem Raspberry Pi 2 wie dem meinen ist das minimale sinnvolle Intervall 90 Sekunden. Bei so einer Konfiguration wäre also ein step von 90 oder höher angesagt.
Das Heartbeat setzt man auf step*2 = 180, weil mal ein Datenwert ausfallen kann ohne dass man eine Lücke sehen will. Aber nicht höher, weil wenn es keine Werte gibt, sollte man keine künstlich generieren.
Das RRA erstellt man dann ohne Konsolidierung, so dass man direkt den Datenwert alle step Sekunden speichert. Der xff ist hier irrelevant, weil nichts konsolidiert wird. Da man aber was eintragen muss, nehmen wir best practice 0.5.
Für 1 Woche sind das 7*24*3600 / 90 = 6720 Datenpunkte.
Also:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 90 \
DS:f00:GAUGE:180:U:U \
[...]
RRA:AVERAGE:0.5:1:6720
Da schrumpft die *.rrd Datei auch gleich um einiges, die *.png Erstellung geht etwas schneller, und es werden nicht weniger Daten gespeichert als zuvor. Die Grafiken hingegen werden so exakt wie die Datenerhebung es erlaubt.
Wenn man längere Zeiträume aufheben möchte, kann die 6720 erhöhen. Man kann aber auch zusätzliche RRAs hinzufügen, die höher aggregierte Werte speichern. Cacti beispielsweise erhebt Daten standardmäßig in 5-Minuten Takt, d.h. das hat einen step von 300. Wir könnten das z.b. hier simulieren und einen auf 300 Sekunden konsolidierten RRA hinzufügen. Leider geht das nicht direkt, weil 300 nicht durch 90 teilbar ist - unsere pdp's haben ja eine Auflösung von 90 Sekunden. Aber wenn wir den step auf 100 hochdrehen, dann sind 3 pdp's 3*100 = 300 Sekunden. Will ich 1 Monat so aufheben, bräuchte ich 31 Tage * 24 Stunden * 3600 Sekunden / 100 / 3 = 8928 Datenpunkte. Der erste rra hätte 7 Tage * 24 Stunden * 3600 Sekunden / 100 = 6048 Datenpunkte.
Also dann:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 100 \
DS:f00:GAUGE:200:U:U \
[...]
RRA:AVERAGE:0.5:1:6048 \
RRA:AVERAGE:0.5:3:8928
Wer ein schnelleres System hat, bei dem in 75 Sekunden alles gescannt werden kann, kann den step auch auf 75 setzen und hätte dann 4*75 = 300 und bräuchte 31 Tage * 24 Stunden * 3600 Sekunden / 75 / 4 = 8928 Datenpunkte. Der erste, nicht konsolidierte RRA für 7 Tage hätte 7 Tage * 24 Stunden * 3600 Sekunden / 75 = 8064 Datenpunkte.
Also:
Bash:
rrdtool create \
test.rrd \
--start 0 --step 75 \
DS:f00:GAUGE:150:U:U \
[...]
RRA:AVERAGE:0.5:1:8064 \
RRA:AVERAGE:0.5:4:8928
Bei den 8 Tunern von no sleep könnte man bis runter auf step=10 gehen, also alle 10 Sekunden. Das wäre so in etwa die Datendichte, die das ursprüngliche rra hat, aber diesmal korrekt aufgebaut.
Das erste rra benötigt 7 Tage * 24 Stunden * 3600 / 10 = 60480 Datenpunkte, das zweite für 31 Tage * 24 Stunden * 3600 / 10 / 30 = 8928
Bash:
rrdtool create \
test.rrd \
--start 0 --step 10 \
DS:f00:GAUGE:20:U:U \
[...]
RRA:AVERAGE:0.5:1:60480 \
RRA:AVERAGE:0.5:4:8928
Bei allen besteht das zweite rra immer aus 8928 Punkten, weil es überall derselbe Zeitraum (31 Tage) mit demselben konsolidierten Intervall (300 Sekunden) ist.

Mein Vorschlag für CableLoadMonitor:
bei der Generierung des rra die minimal mögliche Auflösung abfragen/berechnen/abschätzen und step entsprechend setzen sowie die Anzahl der Datenpunkte entsprechend ausrechnen. De facto allerdings machen Auflösungen unter 120 Sekunden (step=120) wenig Sinn, weil bei niedrigeren Steps zuviele Spikes angezeigt werden und die Grafiken arg ausgefranst werden ohne damit wirklich einen Mehrwert zu bieten. Die bisherige Mittelwert-von-Mittelwert-von-geschätzten Werten Berechnung finde ich ehrlich gesagt nicht ausreichend genau. Die aufgezeichneten Daten sollten möglichst genau das wiederspiegeln, was man gemessen hat. Will man nicht 100% die gemessenen Daten, sondern Trends und gemittelte Werte in der Grafik anzeigen, dann sollte man die dafür vorgesehenen Ausdrücke und berechnete virtuelle Datenquellen bei der Grafikerzeugung nutzen. Aber nicht die Datenwerte schon beim abspeichern verschmieren.
 
Zuletzt bearbeitet:

sparkie

Beiträge
787
Reaktionen
51
@boba :
vielen Dank fuer die ausfuehrliche Abhandlung. Sorry ich muss mir das noch genauer durchlesen.

Du gibst einen step von 1 vor, d.h. dein rrdtool erwartet jede Sekunde einen neuen Messwert. Bei einem Tuner und 31 Kanälen purzelt bei mir in etwa alle 80-90 Sekunden eine Messung heraus. Also hätte man nur jeden 80ten pdp mit Messwert und alle anderen Werte wären UNKNOWN. Damit das jedoch nicht passiert, sondern die Datenbank so lange mit den alten Werten befüllt wird, bis ein neuer Wert kommt, hast du einen heartbeat von 120 angegeben, d.h. bis zu 120 Sekunden lang wird nicht UNKNOWN eingetragen, wenn kein Wert kommt, sondern der vorherige Wert kopiert.
ich wollte die zeitliche Aufloesung in der Darstellung etwa auf die Dauer von ein paar wenigen DS-Kanal Messungen setzen. Das rrdtool bekommt ja eben auch tatsaechlich ca. alle 1 - 2 Sekunden einen neuen Messwert. Im 10 Sekunden Raster werden die Aenderungen dann also recht zeitnah sichtbar. Beispiel siehe Bild gestreckt auf 100s Dauer. Wenn das mit anderen Einstellungen effizienter erreichbar ist dann bitte gerne

CableLoadMonitor.png
 
boba

boba

Beiträge
1.058
Reaktionen
214
Ich habe noch gar nicht so genau auf das tatsächlichen rrdtool update geschaut, sondern nur auf die rrd Erstellung. Hm... stimmt, du erhebst die Daten für einen Kanal und schreibst das dann sofort weg. Aber dann für alle Kanäle, und die nicht ausgelesenen immer mit Daten, die du vom vorherigen Durchgang noch gespeichert hast. Das heißt, du schreibst bei 31 Kanälen 30 mal denselben Wert für einen Kanal.
Ich würde die Daten erst für alle Kanäle auslesen und zwischenspeichern und nach dem letzten Kanal einen einzigen rrdtool update Aufruf machen. So würde das dann zu dem step passen, den ich oben erklärt habe. Das ist zwar seltener, aber mit deinen 10 Sekunden kann man nicht wirklich was anfangen, wenn sich immer nur ein Kanal ändert. So hast du alle step Sekunden ein komplettes Update aller Kanäle und kannst genauer sehen, wie sich die die Auslastung von Intervall zu Intervall ändert. Wenn immer nur 1 Kanal von 31 geändert wird, verschmiert das alles doch.
 

sparkie

Beiträge
787
Reaktionen
51
Ich habe noch gar nicht so genau auf das tatsächlichen rrdtool update geschaut, sondern nur auf die rrd Erstellung. Hm... stimmt, du erhebst die Daten für einen Kanal und schreibst das dann sofort weg. Aber dann für alle Kanäle, und die nicht ausgelesenen immer mit Daten, die du vom vorherigen Durchgang noch gespeichert hast. Das heißt, du schreibst bei 31 Kanälen 30 mal denselben Wert für einen Kanal.
genau. Ich wuesste im Moment auch nicht wie man es viel effizienter hinbekommen koennte. Ich moechte dem rrdtool die Daten eben so frueh wie moeglich zugaenglich machen. Dass dabei bei 31 Kanälen 30 mal denselbe Wert für einen Kanal geschrieben wird entspricht ja zudem genau der gewuenschten Darstellung (siehe Bild oben - Option '-d 1').

Das ist zwar seltener, aber mit deinen 10 Sekunden kann man nicht wirklich was anfangen, wenn sich immer nur ein Kanal ändert. So hast du alle step Sekunden ein komplettes Update aller Kanäle und kannst genauer sehen, wie sich die die Auslastung von Intervall zu Intervall ändert. Wenn immer nur 1 Kanal von 31 geändert wird, verschmiert das alles doch.
das stimmt nicht ganz. Denn ich sehe Aenderungen der Last zum fruehest moeglichen Zeitpunkt. Und nicht erst wenn alle Kanaele komplett gescannt sind. Zudem skaliert es so wie es jetzt implementiert ist optimal mit der Anzahl der vorhandenen Tuner im System. Jeder einzelne Tuner mehr vermindert sofort die sichtbare Reaktionszeit bei Lastwechseln.
 
Zuletzt bearbeitet:

rv112

Beiträge
4.499
Reaktionen
226
Ich scheine es mit dem xbox Tuner zum laufen gebracht zu haben. Vielen Dank für den Tipp!
Die Durchschnitts-Auslastung meines Segments scheint jetzt im Moment so um die 600 mbit zu sein. Auf meinem schon etwas betagten Raspberry Pi 2 dauert ein Scan (31 Kanäle) mit dem einen Tuner um die 90 Sekunden.

Etwas gedauert hat es, bis ich rausgefunden habe, dass für den xbox Tuner noch ein Firmware File namens dvb-demod-mn88472-02.fw fehlt. Ich verwende Centos 7 auf meinem pi, da ist das nicht dabei. Vielleicht unter dem Standard Raspian, wenn das sonst keiner bemerkt hat. Die Datei gibts bei http://palosaari.fi/linux/v4l-dvb/firmware/MN88472/02/latest/dvb-demod-mn88472-02.fw liegt auch in einem armbian github Repository:
https://github.com/armbian/firmware/blob/master/dvb-demod-mn88472-02.fw

Damit das unter Centos 7 geht, musste ich den Source zu dvbtune und dvbsnoop finden und selbst kompilieren. Das Tool dvb-fe-tool gibts im Paket v4l-utils.

Tja, hübsche Bastelei. Ich werde das CableLoadMonitor Skript "ausschlachten" und ein php Modul für mein cacti Monitoring neu machen.
Die dvb Tools dvbtune und dvbsnoop sind uralt, möglicherweise ist ja eines der Tools aus v4l-utils eine Ablösung. Mal schauen.

Das ganze kommt gerade recht, um mit der Einführung des ofdm Kanals für Docsis 3.1 obsolet, oder aber zumindest unvollständig zu werden ;)

Im CableLoadMonitor habe ich einen kleinen Fehler gefunden, und zwar wenn dvb-fe-tool verwendet wird, um zu zählen wieviele Tuner vorhanden sind, dann erkennt er die Zahl nicht und nimmt 20. Mein dvb-fe-tool liefert 255 als return code und nicht -1 bei Fehler:
Bash:
[[email protected] dvb]# dvb-fe-tool -a 0 -d DVBC/ANNEX_A
INFO Device Panasonic MN88472 (/dev/dvb/adapter0/frontend0) capabilities:
INFO CAN_2G_MODULATION
INFO CAN_FEC_1_2
INFO CAN_FEC_2_3
INFO CAN_FEC_3_4
INFO CAN_FEC_5_6
INFO CAN_FEC_7_8
INFO CAN_FEC_AUTO
INFO CAN_GUARD_INTERVAL_AUTO
INFO CAN_HIERARCHY_AUTO
INFO CAN_INVERSION_AUTO
INFO CAN_MULTISTREAM
INFO CAN_MUTE_TS
INFO CAN_QAM_16
INFO CAN_QAM_32
INFO CAN_QAM_64
INFO CAN_QAM_128
INFO CAN_QAM_256
INFO CAN_QAM_AUTO
INFO CAN_QPSK
INFO CAN_TRANSMISSION_MODE_AUTO
INFO DVB API Version 5.11, Current v5 delivery system: DVBC/ANNEX_A
INFO Supported delivery systems:
INFO DVBT
INFO DVBT2
INFO [DVBC/ANNEX_A]
[[email protected] dvb]# echo $?
0
[[email protected] dvb]# dvb-fe-tool -a 1 -d DVBC/ANNEX_A
ERROR No such file or directory while opening /dev/dvb/adapter1/frontend0
[[email protected] dvb]# echo $?
255
Ich habe mir nun auch den XBOX Tuner zugelegt und mittels Raspbian ganz blauäugig gestartet. Leider bringt er mir aber

Code:
no Sundtek card(s) found, trying others (unsupported)
DVB-C tuner(s) found: 1, using thereof: 1
06:43:47:
dvbtune/dvbsnoop fails for [ 482 ] [ 7 != 3 ], retrying...
CMD: sudo systemctl stop sundtek; sleep 5; sudo systemctl start sundtek; sleep 15
Raspbian hat den Tuner aber erkannt. Habe auch zusätzlich den Treiber unter /lib/ abgelegt.

Hier mal noch das Log, auch für @sparkie :

Code:
====== [ 770 ] program start [Thu Jul 23 06:23:50 BST 2020] on rpi2 ======
CableLoadMonitor||||||||||||||||||||
CMD: /bin/bash -c 'ls /root/CableLoadMonitor.cfg' 2>&1
scanning output for: <^(/root/CableLoadMonitor.cfg)$>
/root/CableLoadMonitor.cfg
first match: </root/CableLoadMonitor.cfg>
ex_line open: { cat /root/CableLoadMonitor.cfg; } 2>&1
ex_line close: { cat /root/CableLoadMonitor.cfg; } 2>&1
CMD: /bin/bash -c 'which wget' 2>&1
scanning output for: <(.)>
/usr/bin/wget
first match: </>
CMD: /bin/bash -c 'which gawk' 2>&1
scanning output for: <(.)>
/usr/bin/gawk
first match: </>
CMD: /bin/bash -c 'which lynx' 2>&1
scanning output for: <(.)>
/usr/bin/lynx
first match: </>
CMD: /bin/bash -c 'which dvbsnoop' 2>&1
scanning output for: <(.)>
/usr/bin/dvbsnoop
first match: </>
CMD: /bin/bash -c 'which dvbtune' 2>&1
scanning output for: <(.)>
/usr/bin/dvbtune
first match: </>
CMD: /bin/bash -c 'which dvb-fe-tool' 2>&1
scanning output for: <(.)>
/usr/bin/dvb-fe-tool
first match: </>
CMD: /bin/bash -c 'which rrdtool' 2>&1
scanning output for: <(.)>
/usr/bin/rrdtool
first match: </>
CMD: /bin/bash -c 'which sudo' 2>&1
scanning output for: <(.)>
/usr/bin/sudo
first match: </>
evaluating given downstream channel frequencies
downstream channel frequencies now in use: [ 31 ]
482/QAM256 474/QAM256 490/QAM256 498/QAM256 522/QAM256 530/QAM256 538/QAM256
546/QAM256 554/QAM256 562/QAM256 570/QAM256 578/QAM256 586/QAM256 594/QAM256
602/QAM256 618/QAM256 626/QAM256 634/QAM256 642/QAM256 650/QAM256 658/QAM256
666/QAM256 674/QAM256 682/QAM256 690/QAM256 698/QAM256 706/QAM256 746/QAM256
754/QAM256 762/QAM256 770/QAM256
CMD: /bin/bash -c 'ls /root/CableLoadMonitor.rrd' 2>&1
scanning output for: <^(/root/CableLoadMonitor.rrd)$>
/root/CableLoadMonitor.rrd
first match: </root/CableLoadMonitor.rrd>
graph display mode: standard
graph destination dir: /root/
recording RRA step size: 10 seconds
recording RRA history size: 7 day(s) 0 hour(s) 0 minute(s) 0 second(s)
using multiple DVB-C tuners: in parallel (if applicable)
DVB-C failure recovery method: retry
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
CMD: /bin/bash -c 'echo 0 | sudo tee -a /sys/module/dvb_core/parameters/dvb_powerdown_on_sleep' 2>&1
0
CMD: /bin/bash -c '/opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 --setdtvmode=DVBC' 2>&1
scanning output for: <^(Done)>
Using device: /dev/dvb/adapter0/frontend0
device: /dev/dvb/adapter0/frontend0 doesn't support the extended media API
no match
no Sundtek card(s) found, trying others (unsupported)
CMD: /bin/bash -c 'dvb-fe-tool -a 0 -d DVBC/ANNEX_A' 2>&1
scanning output for: <(not found)>
Changing delivery system to: DVBC/ANNEX_A
no match
CMD: /bin/bash -c 'dvb-fe-tool -a 1 -d DVBC/ANNEX_A' 2>&1
scanning output for: <(not found)>
WARNING device dvb1.frontend0 not found
first match: <not found>
DVB-C tuner(s) found: 1, using thereof: 1
CMD: /bin/bash -c 'ln -nfs /bin/sh /root/sh0' 2>&1
scanning output for: <(.)>
no match
06:23:50: --------------------------------------------------------------------------------
{ LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -c 0 -f 482000000 -s 6952 -qam 256; LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -adapter 0 -s bandwidth 8190 -n 80000; } 2>&1
## PID: 8190 (0x1ffe) bad/total packets: 0/0 (= nan%) Avrg: 0.000 kbit/s
dvbtune/dvbsnoop fails for [ 482 ] [ 7 != 3 ], retrying...
CMD: sudo systemctl stop sundtek; sleep 5; sudo systemctl start sundtek; sleep 15
 
Zuletzt bearbeitet:

rv112

Beiträge
4.499
Reaktionen
226
Argh, natürlich. Ich hatte sie nur nach /lib/ kopiert, jetzt gehts. Danke!
 
  • Gefällt mir
Reaktionen: millen

rv112

Beiträge
4.499
Reaktionen
226
Nachdem nun ein Durchgang durch ist, startet er keinen zweiten Durchgang und wirft mir stattdessen diesen Fehler:

Code:
CMD: /bin/bash -c 'rrdtool update /root/CableLoadMonitor.rrd N:12110000:11071000:14925000:15029000:13613000:9470000:12306000:12959000:9238000:15742000:15436000:12778000:13625000:12597000:13516000:17641000:10308000:12239000:9332000:11952000:14561000:13969000:10453000:9064000:11145000:12616000:13297000:13371000:7337000:10186000:11610000:383496000' 2>&1
383496
scanning output for: <^(.*ERROR.*)$>
2081x1596
no match
CMD: /bin/bash -c 'mv /var/www/html/CableLoadMonitor.png_ /var/www/html/CableLoadMonitor_1h.png' 2>&1
scanning output for: <^(.*ERROR.*)$>
2081x1596
no match
CMD: /bin/bash -c 'mv /var/www/html/CableLoadMonitor.png_ /var/www/html/CableLoadMonitor_6h.png' 2>&1
scanning output for: <^(.*ERROR.*)$>
2081x1596
no match
CMD: /bin/bash -c 'mv /var/www/html/CableLoadMonitor.png_ /var/www/html/CableLoadMonitor_1d.png' 2>&1
scanning output for: <^(.*ERROR.*)$>
Unbenannt.JPG
 

millen

Beiträge
166
Reaktionen
27
Probier bitte mal den command mit sudo zu starten.
 
Thema:

Auslastung des eigenen Segments ansehen (reloaded)

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

  • Auslastung durch aktuelle Corona-Lage

    Auslastung durch aktuelle Corona-Lage: Bis vor wenigen Tagen habe ich nix von irgendwelchen Auslastungen des Netzes durch die Corona-Lage bemerkt, aber seit ca. Montag habe ich immer...
  • Connect Box ping auslastung

    Connect Box ping auslastung: Hallo Zusammen Diese " Werte " sind doch nicht normal Oder ? https://www.directupload.net/file/d/5357/nkwu36cq_jpg.htm RxMER liegt bei 37,5...
  • Auslastung des Netztes

    Auslastung des Netztes: Hallo , Viele Leute schreiben oft von geschwindigkeits einbußesn in den abendstunden . Ich konnte da noch nichts feststellen mit meine 32mbit...
  • Verbindungsabbruch bei Auslastung der Geschwindigkeit

    Verbindungsabbruch bei Auslastung der Geschwindigkeit: Hallo Forum, ich wende mich an euch mit folgendem Problem: 1. Ausstattung FB6360 Firmware-Version 85.04.89-19078 Sync: 70,5 MBit/s 5,5 MBit/s...
  • Auslastung des Internets verschlechtert Telefonqualität

    Auslastung des Internets verschlechtert Telefonqualität: Hallo, wir haben ein Problem, und zwar ist es kaum mehr möglich zu telefonieren, wenn der Downstream bei ca. 1,5MB/s liegt. Es ist dann keinem der...
  • Ähnliche Themen
  • Auslastung durch aktuelle Corona-Lage

    Auslastung durch aktuelle Corona-Lage: Bis vor wenigen Tagen habe ich nix von irgendwelchen Auslastungen des Netzes durch die Corona-Lage bemerkt, aber seit ca. Montag habe ich immer...
  • Connect Box ping auslastung

    Connect Box ping auslastung: Hallo Zusammen Diese " Werte " sind doch nicht normal Oder ? https://www.directupload.net/file/d/5357/nkwu36cq_jpg.htm RxMER liegt bei 37,5...
  • Auslastung des Netztes

    Auslastung des Netztes: Hallo , Viele Leute schreiben oft von geschwindigkeits einbußesn in den abendstunden . Ich konnte da noch nichts feststellen mit meine 32mbit...
  • Verbindungsabbruch bei Auslastung der Geschwindigkeit

    Verbindungsabbruch bei Auslastung der Geschwindigkeit: Hallo Forum, ich wende mich an euch mit folgendem Problem: 1. Ausstattung FB6360 Firmware-Version 85.04.89-19078 Sync: 70,5 MBit/s 5,5 MBit/s...
  • Auslastung des Internets verschlechtert Telefonqualität

    Auslastung des Internets verschlechtert Telefonqualität: Hallo, wir haben ein Problem, und zwar ist es kaum mehr möglich zu telefonieren, wenn der Downstream bei ca. 1,5MB/s liegt. Es ist dann keinem der...