Unitymedia Auslastung des eigenen Segments ansehen (reloaded)

[EDIZ]

ich sehe gerade bei mir, dass bei wenig Last tatsaechlich ein paar der oberen Frequenzen sporadisch 0 kbit/s ausgeben.
Wenn ich aber Last mache dann geht der Level auf allen (bei mir) vorhandenen 16 Frequenzen hoch.

Wahrscheinlich nutzen die meisten Modems in meinem Segment halt nur die 8 unteren Kanaele :smile:

Ich war jetzt gerade mal bei meinem Vater und hab es bei Ihm auch mal getestet und dabei hab ich jetzt folgendes Problem oder Anomalie. Die letzten 10 Frequenzen haben gar keine Pakete. Bei mir sind es nur die letzten 3. Hab die Frequenzen 3 fach gecheckt, weil ich die per Hand eingeben musste. Kann es vllt daran liegen das er nicht seine gebuchten 400 Mbit/s bekommt ? Manche Frequenzen sind bei 600Mbit/s Auslastung am Anschlag aber ändern tut sich bei den Kanälen mit 0 nichts.

15:29:42: 29127 21017 18885 22838 16615 21020 17460 17902 15294 16752 18595 19725 21056 0 0 0 0 0 0 0 0 0 0 27965 284251
15:32:38: 21968 23914 30300 26675 33166 25168 24967 25952 16009 21170 22637 18221 752 0 0 0 0 0 0 0 0 0 0 25436 316335
15:35:37: 27816 27760 30035 29135 29293 24559 30483 26959 34134 41507 31737 29350 1504 0 0 0 0 0 0 0 0 0 0 22722 386994
15:38:44: 25511 32002 29060 32862 23558 25034 24678 40286 25014 25751 25788 1003 0 0 0 0 0 0 0 0 0 0 0 28988 339535
15:41:52: 29521 29627 30453 28171 29326 23820 22358 27143 37641 40880 24705 27882 0 0 0 0 0 0 0 0 0 0 0 32811 384338
15:44:53: 27707 25425 26572 31485 25121 26603 29655 23608 22951 28085 23393 20869 6768 0 0 0 0 0 0 0 0 0 0 29244 347486
15:47:59: 28364 22263 24805 25126 27867 27653 24741 40214 21400 26958 24927 25422 752 0 0 0 0 0 0 0 0 0 0 31903 352395
15:51:03: 30101 32519 25699 32319 34166 30330 27573 31252 33842 35735 37139 25583 3384 0 0 0 0 0 0 0 0 0 0 24201 403843
15:54:06: 24389 26093 21384 27443 24076 26723 23515 25007 32381 19751 23559 24229 301 0 0 0 0 0 0 0 0 0 0 23593 322444
15:57:11: 26421 31227 27313 23325 28899 22759 27881 38420 25279 20925 20383 22446 7520 0 0 0 0 0 0 0 0 0 0 21167 343965
16:00:16: 33133 40653 40485 27462 21047 23709 23259 30379 19042 22522 37288 23405 12032 0 0 0 0 0 0 0 0 0 0 21400 375816
16:03:21: 41441 25472 25822 27826 26424 30405 29145 39796 23801 42101 31877 30597 3008 0 0 0 0 0 0 0 0 0 0 26118 403833
16:06:28: 24010 30916 26256 27698 30575 32945 25050 26285 21564 21718 25901 23385 13536 0 0 0 0 0 0 0 0 0 0 27989 357828
16:09:31: 22217 26371 26334 28746 31784 26522 25553 32258 28011 27835 27090 29952 3760 0 0 0 0 0 0 0 0 0 0 19884 356317
16:12:31: 25904 26473 20817 24290 25255 24941 27333 27101 22416 21602 26393 20093 0 0 0 0 0 0 0 0 0 0 0 20409 313027
16:15:33: 24901 24827 21959 26714 22650 27326 19338 20805 28142 34088 24183 19603 12784 0 0 0 0 0 0 0 0 0 0 25493 332813
16:18:39: 23419 34345 22223 31355 27646 30127 24980 39969 25036 27412 20839 22313 0 0 0 0 0 0 0 0 0 0 0 25348 355012
16:21:43: 22158 29887 26377 19937 22419 25666 23451 21625 24183 22494 22820 13536 0 0 0 0 0 0 0 0 0 0 0 21061 295614
16:24:50: 24873 29458 25174 33596 24661 22953 25002 27906 22243 20408 25409 22336 3008 0 0 0 0 0 0 0 0 0 0 23626 330653
16:27:48: 20802 27526 23599 25177 20608 27083 21932 25009 24891 24130 26061 23622 4136 0 0 0 0 0 0 0 0 0 0 21777 316353
16:30:52: 25140 22889 19477 23123 26745 21459 16145 28136 25329 16922 27194 20223 8272 0 0 0 0 0 0 0 0 0 0 23930 304984
16:33:55: 28060 24354 24717 27668 19889 22700 23550 18555 21440 19082 24201 21541 10528 0 0 0 0 0 0 0 0 0 0 24047 310332
16:36:59: 29412 32746 29521 24466 25924 25965 31752 28379 21678 22176 23142 26087 752 0 0 0 0 0 0 0 0 0 0 36909 358909
16:40:04: 33129 39190 28459 27513 24615 22828 23110 21987 22390 23059 23666 26959 4512 0 0 0 0 0 0 0 0 0 0 27913 349330
16:43:03: 39839 48336 38525 35061 39130 37239 39854 42725 39545 39397 34139 42569 5414 0 0 0 0 0 0 0 0 0 0 34384 516157
16:46:03: 28246 27135 28653 33494 33403 33151 37689 27063 26464 28397 33897 23783 0 0 0 0 0 0 0 0 0 0 0 23468 384843
16:49:07: 27422 34766 26475 34740 30852 27831 42918 43288 34757 32202 39934 37484 2256 0 0 0 0 0 0 0 0 0 0 44810 459735
16:52:14: 46204 47257 36705 31570 39408 42068 47785 36989 34527 31182 38193 41796 3384 0 0 0 0 0 0 0 0 0 0 44263 521331
16:55:21: 40754 44345 47958 49868 48012 48029 33971 39887 27413 33268 34778 37905 3384 0 0 0 0 0 0 0 0 0 0 48420 537992

 

[sparkie]

zeigt denn das Modem Pakete auf den besagten Frequenzen an? Ist der Modemanschluss identisch zum DVB-C Tuner Anschluss (d.h. keine Filter etc. vorgelagert)?

Wenn man selbst einen Download mit einer bestimmten Datenrate startet, dann muss das ja mit einem entsprechenden Anstieg der Auslastung im Segment einhergehen.

 

[EDIZ]

zeigt denn das Modem Pakete auf den besagten Frequenzen an? Ist der Modemanschluss identisch zum DVB-C Tuner Anschluss (d.h. keine Filter etc. vorgelagert)?

Wenn man selbst einen Download mit einer bestimmten Datenrate startet, dann muss das ja mit einem entsprechenden Anstieg der Auslastung im Segment einhergehen.

Kann man das bei der Connectbox irgendwie sehen? Ne, keine Filter oder ähnliches. Ja ist an der selben Dose wie das Modem. Aber ich verstehe halt nicht warum es bei mir nur 3 sind und bei Ihm 10. Sind ja sogar die selben Frequenzen wie bei mir. Also liegt es nicht am DVB Stick oder ?

 

[EDIZ]

zeigt denn das Modem Pakete auf den besagten Frequenzen an? Ist der Modemanschluss identisch zum DVB-C Tuner Anschluss (d.h. keine Filter etc. vorgelagert)?

Wenn man selbst einen Download mit einer bestimmten Datenrate startet, dann muss das ja mit einem entsprechenden Anstieg der Auslastung im Segment einhergehen.

Ist eine Fehlkonfiguration von UM möglich? Sodass die hinteren Frequenzen wirklich nicht genutzt werden und die vorderen deswegen an den Anschlag gehen ? Bei mir mit 600Mbit/s Auslastung waren die Kanäle nur mit max 33 Mbit/s ausgelastet.

 

[sparkie]

Kann man das bei der Connectbox irgendwie sehen?

vermutlich eher nicht. Da hilft nur noch ein TC4400

Also liegt es nicht am DVB Stick oder ?

bekommt der Tuner denn wenigstens einen Lock auf den besagten Frequenzen (sichtbar im Logfile)?

Ist eine Fehlkonfiguration von UM möglich?

keine Ahnung was UM da moeglicherweise wieder veranstaltet. Vielleicht mal direkt bei UM anfragen :smile:

 

[EDIZ]

Kann man das bei der Connectbox irgendwie sehen?

vermutlich eher nicht. Da hilft nur noch ein TC4400

Also liegt es nicht am DVB Stick oder ?

bekommt der Tuner denn wenigstens einen Lock auf den besagten Frequenzen (sichtbar im Logfile)?

Ist eine Fehlkonfiguration von UM möglich?

keine Ahnung was UM da moeglicherweise wieder veranstaltet. Vielleicht mal direkt bei UM anfragen :smile:

Hier aus dem logfile einer der Kanäle wo nichts kommt.
UM wird mir gar nichts sagen. ;D

CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -f 642000000 -s 6952 -qam 256' 2>&1
scanning output for: <Bit error rate: ([0-9]+)$>
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Using DVB card "Sony CXD2837ER DVB-T/T2/C demodulator"
tuning DVB-C to 642000000, srate=6952000
polling....
Getting frontend event
FE_STATUS:
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
first match: <0>
Signal strength: 511
SNR: 0
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -s bandwidth 8190 -n 80000' 2>&1
scanning output for: <^## PID:.*Avrg: +([^ ]+) >
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/

 

[sparkie]

ok, FE_STATUS schaut gut aus. Waere interessant ob es UM-Nutzer mit TC4400 gibt, bei denen auf bestimmten Frequenzen keine code-words zu sehen sind...

 

[robert_s]

Wenn auf einem Kanal gar keine Pakete mit PID 8190 kommen, ist das schlichtweg kein DOCSIS-Kanal. Denn selbst wenn es keine Daten zu übertragen gibt, muss mindestens regelmässig der MDD gesendet werden.

@EDIZ, wenn Du mal 30-60s eines Kanals, auf dem was mit PID 8190 kommt, abspeichern und irgendwo zur Verfügung stellen kannst, könnte ich mal nach dem MDD sehen, welche Frequenzen bei Dir wirklich mit DOCSIS belegt sein sollten.

 

[EDIZ]

Wenn auf einem Kanal gar keine Pakete mit PID 8190 kommen, ist das schlichtweg kein DOCSIS-Kanal. Denn selbst wenn es keine Daten zu übertragen gibt, muss mindestens regelmässig der MDD gesendet werden.

@EDIZ, wenn Du mal 30-60s eines Kanals, auf dem was mit PID 8190 kommt, abspeichern und irgendwo zur Verfügung stellen kannst, könnte ich mal nach dem MDD sehen, welche Frequenzen bei Dir wirklich mit DOCSIS belegt sein sollten.

Wie mache ich das am besten ?

 

[EDIZ]

ok, FE_STATUS schaut gut aus. Waere interessant ob es UM-Nutzer mit TC4400 gibt, bei denen auf bestimmten Frequenzen keine code-words zu sehen sind...

Bei mir daheim sehen die letzten 3 Kanäle so aus. Denke mal das er einfach kein Signal kriegt oder ?

## PID: 8190 (0x1ffe) bad/total packets: 0/0 (= -nan%) Avrg: 0.000 kbit/s
first match: <0.000>
... aborted (Signal: 15) 0CMD: /bin/bash -c 'rrdtool update /home/ediz/CableLoadMonitor.rrd N:0:0:0:0' 2>&1
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -f 762000000 -s 6952 -qam 256' 2>&1
scanning output for: <Bit error rate: ([0-9]+)$>
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Using DVB card "Sony CXD2837ER DVB-T/T2/C demodulator"
tuning DVB-C to 762000000, srate=6952000
polling....
Getting frontend event
FE_STATUS:
polling....
no match
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -s bandwidth 8190 -n 80000' 2>&1
scanning output for: <^## PID:.*Avrg: +([^ ]+) >
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/

 

[sparkie]

weiter oben im Logfile war der FE_STATUS aber noch in Ordnung. Wenn der FE_STATUS leer bleibt (wie hier) bekommt der dvbsnoop natuerlich erst recht keine Werte. Was die genaue Ursache dafuer ist kann man daraus nicht erkennen.

 

[EDIZ]

ok, FE_STATUS schaut gut aus. Waere interessant ob es UM-Nutzer mit TC4400 gibt, bei denen auf bestimmten Frequenzen keine code-words zu sehen sind...

Sry hab mich in der Zeile vertan. 642 kamen noch pakete ab 666 kam nichts mehr. Auf 658 kamen noch 18 Pakete aber das FE_Status sah gleich aus.

scanning output for: <Bit error rate: ([0-9]+)$>
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Using DVB card "Sony CXD2837ER DVB-T/T2/C demodulator"
tuning DVB-C to 658000000, srate=6952000
polling....
Getting frontend event
FE_STATUS:
polling....
no match
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -s bandwidth 8190 -n 80000' 2>&1
scanning output for: <^## PID:.*Avrg: +([^ ]+) >
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
---------------------------------------------------------
PID bandwidth statistics...
PID: 8190 (0x1ffe) - max packet count: 80000
---------------------------------------------------------
packets read: 18/(18) d_time: 0.005 s = 5414.400 kbit/s (Avrg: 5414.400 kbit/s) [bad: 2]
## PID: 8190 (0x1ffe) bad/total packets: 2/18 (= 11.1%) Avrg: 5414.400 kbit/s
first match: <5414.400>
... aborted (Signal: 15) 5414CMD: /bin/bash -c 'rrdtool update /home/ediz/CableLoadMonitor.rrd N:39839000:48336000:38525000:35061000:39130000:37239000:39854000:42725000:39545000:39397000:34139000:42569000:5414000:0:0:0:0:0:0:0:0:0:0:27913000:509686000' 2>&1
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 10 dvbtune -f 666000000 -s 6952 -qam 256' 2>&1
scanning output for: <Bit error rate: ([0-9]+)$>
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Using DVB card "Sony CXD2837ER DVB-T/T2/C demodulator"
tuning DVB-C to 666000000, srate=6952000
polling....
Getting frontend event
FE_STATUS:
polling....
no match
CMD: /bin/bash -c 'LD_PRELOAD=/opt/lib/libmediaclient.so timeout 1 dvbsnoop -s bandwidth 8190 -n 80000' 2>&1
scanning output for: <^## PID:.*Avrg: +([^ ]+) >
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/opt/lib/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/
---------------------------------------------------------
PID bandwidth statistics...
PID: 8190 (0x1ffe) - max packet count: 80000
---------------------------------------------------------
## PID: 8190 (0x1ffe) bad/total packets: 0/0 (= -nan%) Avrg: 0.000 kbit/s

 

[EDIZ]

weiter oben im Logfile war der FE_STATUS aber noch in Ordnung. Wenn der FE_STATUS leer bleibt (wie hier) bekommt der dvbsnoop natuerlich erst recht keine Werte. Was die genaue Ursache dafuer ist kann man daraus nicht erkennen.

Das eine war bei meinem Vater das andere bei mir daheim. Er kriegt ab 658 keinen FE_STATUS mehr und ich ab 754 nicht mehr.

 

[robert_s]

@EDIZ, wenn Du mal 30-60s eines Kanals, auf dem was mit PID 8190 kommt, abspeichern und irgendwo zur Verfügung stellen kannst, könnte ich mal nach dem MDD sehen, welche Frequenzen bei Dir wirklich mit DOCSIS belegt sein sollten.

Wie mache ich das am besten ?

Hmm, Du könntest es mal mit dvbstream versuchen:

dvbstream -f 642000 -s 6952000 -qam 256 -n 60 8192 -o:docsis642.ts

 

[EDIZ]

@EDIZ, wenn Du mal 30-60s eines Kanals, auf dem was mit PID 8190 kommt, abspeichern und irgendwo zur Verfügung stellen kannst, könnte ich mal nach dem MDD sehen, welche Frequenzen bei Dir wirklich mit DOCSIS belegt sein sollten.

Wie mache ich das am besten ?

Hmm, Du könntest es mal mit dvbstream versuchen:

dvbstream -f 642000 -s 6952000 -qam 256 -n 60 8192 -o:docsis642.ts

Alles klar! Ich mache es mal hier bei meinem 752er+ Kanal und nächstes Wochenende bei meinem Vater.

 

[Mr.Goodcat]

Seit dem Update von Raspbian auf Kernel 4.19.25-v7+ spuckte mein Hauppauge WinTV-dualHD nur noch für den ersten Kanal im Scan richtige Werte aus. Wenn man zwischen dvbtune und dvbsnoop jedoch eine halbe Sekunde wartet ist alles wieder wie es sein soll. cfreak:
Ich nehme an, dass es mit dem neuen Treiber im Kernel einfach länger dauert bis der Kanal sauber drin ist. Am schönsten wäre es wenn der zweite Kanal des Tuners den Scan beschleunigen würde, aber da scheitert es bei mir grade noch :traurig:

 

[robert_s]

Seit dem Update von Raspbian auf Kernel 4.19.25-v7+ spuckte mein Hauppauge WinTV-dualHD nur noch für den ersten Kanal im Scan richtige Werte aus.

Vielleicht seitdem meine Patches für den WinTV-dualHD Treiber drin sind? :mussweg:

Was läuft denn jetzt falsch? Ich habe den NULL-Packet-Filter deaktiviert, weil ich die NULL-Pakete zur Ermittlung der Segmentauslastung benötige. Vorher kam ich auf jedem Kanal auf fast 100%, weil der Stick nur die DOCSIS-Pakete weitergeleitet hatte...

Ich nehme an, dass es mit dem neuen Treiber im Kernel einfach länger dauert bis der Kanal sauber drin ist. Am schönsten wäre es wenn der zweite Kanal des Tuners den Scan beschleunigen würde, aber da scheitert es bei mir grade noch :traurig:

Ich benutze den einen Tuner, um alle 15 Minuten alle 32 EuroDOCSIS 3.0 Kanäle durchzuscannen und die Segmentauslastung zu ermitteln. Der andere Tuner empfängt dagegen ständig den "Einstiegskanal" auf 602MHz, um dort Registration Responses abzugreifen, zur Tarif- und Modemidentifizierung.

 

[Mr.Goodcat]

Was läuft denn jetzt falsch? Ich habe den NULL-Packet-Filter deaktiviert, weil ich die NULL-Pakete zur Ermittlung der Segmentauslastung benötige. Vorher kam ich auf jedem Kanal auf fast 100%, weil der Stick nur die DOCSIS-Pakete weitergeleitet hatte...

Die Datenrate der einzelnen Kanäle ist einfach viel zu niedrig. Die Ausgabe sieht dann z.B. so aus:

21:11:18: 15540 3818 3819 4168

Nur der erste Wert ist in der passenden Größenordnung. Dabei spielt es keine Rolle auf welche Frequenz der als erstes gescannte Kanal liegt. Wenn man dvbsnoop jedoch den Mittelwert über einen längeren Zeitraum bilden lässt - oder wie beschrieben vor dvbsnoop eine halbe Sekunde wartet - sehen die Werte wieder realistischer aus. Daher gehe ich davon aus, dass es etwas länger als vor dem Update dauert bis der Tuner den Kanal wirklich sauber empfängt. Das Entfernen eines Filters, und damit von Rechenaufwand, sollte hier eigentlich eher positive Auswirkungen haben? Der Spaß läuft auf einem RasPi2 der außer DOCSIS loggen und NTP nichts zu tun hat.

Ich benutze den einen Tuner, um alle 15 Minuten alle 32 EuroDOCSIS 3.0 Kanäle durchzuscannen und die Segmentauslastung zu ermitteln. Der andere Tuner empfängt dagegen ständig den "Einstiegskanal" auf 602MHz, um dort Registration Responses abzugreifen, zur Tarif- und Modemidentifizierung.

Das klingt nach Spaß Das Skript oder eine Anleitung dazu liegt nicht zufällig in einem öffentlichen Git? Stecke nicht tief genug in DOCSIS drin um mir selber Tarife und Modems des Segments rausziehen zu können :traurig:

 

[robert_s]

Die Datenrate der einzelnen Kanäle ist einfach viel zu niedrig. Die Ausgabe sieht dann z.B. so aus:

21:11:18: 15540 3818 3819 4168

Sorry, ich habe mich mit dem Script/Tool nicht befasst. Was sollen die 4 Zahlen denn darstellen, und wie sieht ein richtiges Ergebnis aus?

Daher gehe ich davon aus, dass es etwas länger als vor dem Update dauert bis der Tuner den Kanal wirklich sauber empfängt.

Bei meinem Tool schmeiße ich immer die ersten 8192 erhaltenen Transport Stream Pakete weg. Nicht erst mit der WinTV-dualHD - DVB-C Demodulatoren hatten schon immer die Angewohnheit, beim Kanalwechsel erst mal einige fehlerhafte Pakete auszuspucken.

Möglicherweise war ja vorher auch irgendwo im Treiber eine Verzögerung hinterlegt, sodass das Streamen erst begann, nachdem der Demodulator sich "eingeschwungen" hat. Wenn es die gab und die nun entfernt wurde, muss eben die Applikation auf einen "sauberen Stream" warten...

Das Entfernen eines Filters, und damit von Rechenaufwand, sollte hier eigentlich eher positive Auswirkungen haben?

Nein, negative. Vorher hat der Demodulatorchip die NULL-Pakete praktisch "kostenlos" weggelassen, jetzt werden die alle übertragen und müssen vom Hauptprozessor verarbeitet werden - der Rechenaufwand steigt also.

Wenn Du mit beiden Tunern gleichzeitig zwei 256-QAM Kanäle empfängt, schaufelt der Stick über 100Mbit/s per USB in den PC. Erfreulicherweise geht das tatsächlich fehlerfrei, selbst mit meinem alten NAS mit dem 2,0GHz single-core ARM Kirkwood.

Das klingt nach Spaß Das Skript oder eine Anleitung dazu liegt nicht zufällig in einem öffentlichen Git?

Ist kein Script, sondern inzwischen eine ganze Suite von selbst in C/C++ programmierten Tools. Bislang unveröffentlicht, da ich kaum Zeit und Lust habe, ein öffentliches Repository zu pflegen. Und eins mit "last change: x years ago" sieht nicht so toll aus...

 

[Mr.Goodcat]

Sorry, ich habe mich mit dem Script/Tool nicht befasst. Was sollen die 4 Zahlen denn darstellen, und wie sieht ein richtiges Ergebnis aus?

Der Auszug stellt eine nach vier Kanälen abgebrochene Messung dar. Das Skript gibt erst die aktuelle Uhrzeit aus. Danach wird der Reihe nach (in der Folge wie das TC4400 die Kanäle erfasst hat) die Datenrate der einzelnen Kanäle, sowie zuletzt die Summe angegeben. Der Loop welcher dies steuert, setzt den Tuner erst per dvbtune auf den Kanal und startet fast direkt danach dvbsnoop für die Datenratenmessung.

Bei meinem Tool schmeiße ich immer die ersten 8192 erhaltenen Transport Stream Pakete weg. Nicht erst mit der WinTV-dualHD - DVB-C Demodulatoren hatten schon immer die Angewohnheit, beim Kanalwechsel erst mal einige fehlerhafte Pakete auszuspucken.

Möglicherweise war ja vorher auch irgendwo im Treiber eine Verzögerung hinterlegt, sodass das Streamen erst begann, nachdem der Demodulator sich "eingeschwungen" hat. Wenn es die gab und die nun entfernt wurde, muss eben die Applikation auf einen "sauberen Stream" warten...

Das kann ich nicht beurteilen. Es fällt nur auf, dass es mit dem alten Kernel auch ohne eingefügte Pause lief.

Nein, negative. Vorher hat der Demodulatorchip die NULL-Pakete praktisch "kostenlos" weggelassen, jetzt werden die alle übertragen und müssen vom Hauptprozessor verarbeitet werden - der Rechenaufwand steigt also.

Wenn Du mit beiden Tunern gleichzeitig zwei 256-QAM Kanäle empfängt, schaufelt der Stick über 100Mbit/s per USB in den PC. Erfreulicherweise geht das tatsächlich fehlerfrei, selbst mit meinem alten NAS mit dem 2,0GHz single-core ARM Kirkwood.

OK, ich dachte es würde sich um eine Filterung handeln die auf dem Pi durchgeführt wird. Wenn hier nun mehr Daten über USB geschaufelt und auf der CPU verarbeitet werden müssen kann das schon der Auslöser sein.

Ist kein Script, sondern inzwischen eine ganze Suite von selbst in C/C++ programmierten Tools. Bislang unveröffentlicht, da ich kaum Zeit und Lust habe, ein öffentliches Repository zu pflegen. Und eins mit "last change: x years ago" sieht nicht so toll aus...

Ach was, erst wenn die letzte Änderung Jahre her ist handelt es sich um Software die wirklich stable ist... :zwinker:

 

[sparkie]

Das kann ich nicht beurteilen. Es fällt nur auf, dass es mit dem alten Kernel auch ohne eingefügte Pause lief.

was da in den neuen Kernel-Treibern veranstaltet wird sehe ich nicht, da meine Referenz-Installation mit Sundtek Sticks ihre eigenen Treiber mitbringt.
Aber du koenntest alternativ statt zu warten den Schrott einfach weglesen, bevor die eigentliche Messung beginnt.

Also vielleicht ein

<i>
</i>ex(LD_PL "timeout 1 dvbsnoop -s bandwidth 8190 -n 1000", 4)

vor den eigentlichen 'dvbsnoop' stellen? Vielleicht hilft das auch schon.

 

[Mr.Goodcat]

Also vielleicht ein

<i>
</i>ex(LD_PL "timeout 1 dvbsnoop -s bandwidth 8190 -n 1000", 4)

vor den eigentlichen 'dvbsnoop' stellen? Vielleicht hilft das auch schon.

Ja das funktioniert auch. Wobei auf meinem System alles zum Erfolg führt, dass ca. >0,4s Verzögerung nach der Ausführung von dvbtune einfügt.

 

[Wetter]

Hallo,
ich habe den Thread nun auch mal "endlich" entdeckt und alles soweit zum laufen bekommen. Ich nutze ein PCTV tripleStick HD 292e TV.
Damit der Raspi das Ding richtig verwenden kann, muss die FW eingespielt werden

<i>
</i>sudo wget http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/dvb-demod-si2168-02.fw -O /lib/firmware/dvb-demod-si2168-02.fw

Dank der Informationen hier im Thread, muss dann nur noch auf DBV-C umgeschaltet werden

<i>
</i>sudo dvb-fe-tool -d DVBC/ANNEX_A

Und danach kann ich das Script schon ausführen.
Funktioniert soweit ganz gut.

Da ich aber ein Linux Pleb bin und die Ausführungen auf GitHub nicht vollständig verstehe:
Wie bekomme ich mehr als 1 Diagramm erstellt?
Aktuell wird das Script so aufgerufen

<i>
</i>sudo sh CableLoadMonitor -f 546:474:482:490:498:522:530:546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770

Was muss ich da variieren? Meine "Ziele" wären neben den 1h Bild, auch ein 24h Bild und 7 Tage, 1 Monate, 1 Jahr.

Danke schonmal in Vorraus.

 

[sparkie]

ich habe den Thread nun auch mal "endlich" entdeckt und alles soweit zum laufen bekommen. Ich nutze ein PCTV tripleStick HD 292e TV.

super, danke fuer die Info!

Wie bekomme ich mehr als 1 Diagramm erstellt?

der Hauptprozess (Daemon) zeichnet fortlaufend ueber eine vorgebbare Zeitspanne auf und generiert hieraus auch gleich ein *.png File ueber einen konfigurierbaren Zeitabschnitt. Unabhangig davon kann man sich mit einem weiteren Programmaufruf (Single Shot) beliebige Zeitabschnitte aus der Datenbasis ausgeben (generieren lassen).

Aktuell wird das Script so aufgerufen

<i>
</i>sudo sh CableLoadMonitor -f 546:474:482:490:498:522:530:546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770

per default wird nur ueber eine Woche aufgezeichnet. Fuer 1 Jahr muesste der Aufruf so abgeaendert werden:

<i>
</i>sudo sh CableLoadMonitor -f 546:474:482:490:498:522:530:546:554:562:570:578:586:594:602:618:626:634:642:650:658:666:674:682:690:698:706:746:754:762:770 -c 10 -r 31536000

Achtung: eine bereits generierte Datenbasis CableLoadMonitor.rrd wird dabei neu erstellt. Bei Bedarf vorher evtl. einen Backup davon erstellen. Das muesste ich evtl. im SCript mal automatisch bewerkstelligen :smile:
Falls du den Daemon mal neu starten willst, dann ab jetzt ohne '-c 10 -r 31536000' Option, da sonst die Datenbasis (unnoetigerweise) neu erzeugt wird. Das muss ich im Script mal fixen sehe ich gerade.

Was muss ich da variieren? Meine "Ziele" wären neben den 1h Bild, auch ein 24h Bild und 7 Tage, 1 Monate, 1 Jahr.

die 1 Stunde wird bereits von obigem Aufruf generiert. Wenn du zusaetzlich noch 24h 7 Tage, 1 Monate, 1 Jahr benoetigst dann koennen die (parallel zum weiter laufenden Daemon Prozess) wie folgt erzeugt und mit 'feh' ausgegeben werden:

<i>
</i># 1 Tag
CableLoadMonitor -w 86400 -g; feh CableLoadMonitor.png
# 1 Woche
CableLoadMonitor -w 604800 -g; feh CableLoadMonitor.png
# 1 Monat
CableLoadMonitor -w 2592000 -g;feh CableLoadMonitor.png
# 1 Jahr
CableLoadMonitor -w 31536000 -g;feh CableLoadMonitor.png

diese Aufrufe laufen dann nicht als Daemon sondern beenden sich nach Erzeugen des betreffenden *.png Files sofort wieder.

 

[Wetter]

die 1 Stunde wird bereits von obigem Aufruf generiert. Wenn du zusaetzlich noch 24h 7 Tage, 1 Monate, 1 Jahr benoetigst dann koennen die (parallel zum weiter laufenden Daemon Prozess) wie folgt erzeugt und mit 'feh' ausgegeben werden:

<i>
</i># 1 Tag
CableLoadMonitor -w 86400 -g; feh CableLoadMonitor.png
# 1 Woche
CableLoadMonitor -w 604800 -g; feh CableLoadMonitor.png
# 1 Monat
CableLoadMonitor -w 2592000 -g;feh CableLoadMonitor.png
# 1 Jahr
CableLoadMonitor -w 31536000 -g;feh CableLoadMonitor.png

diese Aufrufe laufen dann nicht als Daemon sondern beenden sich nach Erzeugen des betreffenden *.png Files sofort wieder.

Danke dir sehr.
Ich habe es versucht, bekomme aber folgene Meldung:

<i>
</i>pi@raspberrypi:~ $ CableLoadMonitor -w 86400 -g; feh CableLoadMonitor.png
-bash: CableLoadMonitor: Kommando nicht gefunden.
feh ERROR: Can't open X display. It *is* running, yeah?

Versuche ich es mit sh

<i>
</i>sudo sh CableLoadMonitor -w 86400 -g; feh CableLoadMonitor.png
reading downstream channel frequencies from cache
downstream channel frequencies now in use: [ 31 ] 546 474 482 490 498 522 530 546 554 562 570 578 586 594 602 618 626 634 642 650 658 666 674 682 690 698 706 746 754 762 770
point in time where the displayed graph ends: now
time span covered by the displayed graph: 86400s
feh ERROR: Can't open X display. It *is* running, yeah?

Was mache ich falsch?

eine andere Frage: wenn ich die png varrieren möchte, geht das auch nicht.

<i>
</i>CableLoadMonitor -w 86400 -g; feh CableLoadMonitor_1Day.png
-bash: CableLoadMonitor: Kommando nicht gefunden.
feh WARNING: CableLoadMonitor_1Day.png does not exist - skipping
feh: No loadable images specified.
See 'man feh' for detailed usage information

:hirnbump: