Auslastung des eigenen Segments ansehen

[Knidel]

Wie ihr vielleicht in dem globalen Thema gesehen habt, hatte ich vor wenigen Wochen nach Tester für mein Enigma2-Plugin gesucht. Das Plugin sollte die Auslastungen messen und ans KDG-Helpdesk übermitteln.
In Verbindung mit Dreamboxen funktioniert das auch recht gut (wie bei meinen Dreamboxen seit einem halben Jahr). Bei den VU+ Receivern gibt es starke Probleme, die ich nicht nachvollziehen kann. Ich werde das Projekt u.a. deswegen wahrscheinlich nicht weiter verfolgen.

Technisch funktioniert das so, dass während der Receiver im Soft-Standby ist, Messungen in bestimmten Abständen durchgeführt werden. Hierbei wird regelmäßig nach den verfügbaren Downstream-Kanälen im Kabelnetz gesucht und die MAC-Adressen des CMTS ermittelt. Die MAC-Adressen dienen zur Identifizierung des Segments und für das Wochen-Diagramm zur Zusammenfassung der Channel-Bondings. Geplant wäre auch noch ein C++ Programm gewesen, wodurch das Projekt nicht auf Enigma2-Nutzer beschränkt gewesen wäre.

Die Messungen in meinem Segment können hier eingesehen werden:
http://helpdesk.kdgforum.de/docsis/view.php?s=11

[Zettel]

Kann mir jemand von den Experten mal sagen, warum mein Sundtek Stick sich immer wieder "abmeldet"?

[ externes Bild ]

Mein kleiner RPI schreibt dann immer so was, wenn ich versuche das per Hand zu starten:

Error(6): /dev/dvb/adapter0/dvr0: No such device or address
Error during dvb snoop

[fLoo]

Genau das gleiche habe ich hier auch. Sowohl mit dem Sundtek MediaPro I als auch mit dem ganz neuen IIIer aus der Produktion 2014. Ich habe mir bereits ein undervolted MiniITX-System gebaut, welches mit ~ 20 Watt das Logging (und ein paar andere Dinge) übernehmen wird. Keine Lust mehr auf den Scheiss.

[Sundtek]

In welchen Abständen ist das bei euch passiert?

Unsere Teststrecke ist nun auch so ziemlich vorbereitet damit wir längere Tests mit dem Raspberry PI vornehmen können. Wir powern den RPI jedoch mit einem Industrienetzteil.
Ein "Abmelden" hatten wir auch als wir den Raspberry PI mit zu wenig Strom versorgt hatten, aber langfristige Tests haben wir soweit auch noch nicht hinter uns.

Die Netzteilproblematik wurde auch bereits in unserem Forum erwähnt.
Zudem sollte der RPI Made in UK sein (die Chinaversion stürzt gerne mal ab).

Laut unserem Netzteil werden im Durchschnitt ca 0.7-0.8A 5V benötigt, das Netzteil ist auf 5V 2A eingestellt, ich denke selbst bei 1A ist bei uns das USB Device verschwunden, bei 2A ist der RPI noch aktiv.
Das Netzteil sollte stabilisiert sein.

Nach 9 Stunden wo alle 3 Sekunden der Datentransfer gemessen wird gibt es aktuell keine Auffälligkeiten.
Also überprüft eure Netzteile mit dem Raspberry PI.

lsusb eingeben -> Verbrauch springt auf 0.76A
dmesg eingeben -> Verbrauch springt auf 0.79A
Idle (nicht ganz Idle im Hintergrund wurde noch der Tuner verwendet, es war lediglich eine andere Konsole) -> 0.70A

Ah und bezüglich sollte etwas "ruckeln" schaut euch den scaling governor an /sys/devices/system/cpu/cpu0/cpufreq dort könnt ihr Einstellungen vornehmen welche den RPI 700 bzw. 900 MHz laufen lässt wir hatten in der Vergangenheit bereits Probleme mit Systemen welche den Tuner verwendet haben und während dessen die CPU Frequenz umgeschalten wurde, diese sollte Konstant eingestellt sein wenn der Tuner verwendet wird.

Ansonsten läuft das System nun länger als 12 Stunden ohne Probleme.

[koaschten]

Jetzt muss ich euch aber mal HART auf die Füsse treten, wenn ihr testet, dann Realitätsnah. Also entweder mit einem "Handy Ladegerät" oder einem powered USB Hub. Ein stabilisiertes Labornetzteil... echt mal, das kostet mal leicht das 10-fache vom Rest.

[ritchie]

In welchen Abständen ist das bei euch passiert?

Manchmal lief er 2 Tage durch, manchmal kamen die Hänger nach wenigen Minuten.

Unsere Teststrecke ist nun auch so ziemlich vorbereitet damit wir längere Tests mit dem Raspberry PI vornehmen können. Wir powern den RPI jedoch mit einem Industrienetzteil.

Habt ihr den Stick an einem Hub mit eigener Stromversorgung oder direkt am Pi? Eigentlich dürfte er direkt am Pi gar nicht funktionieren, oder nur für kurze Zeit.

Ich verwende ein beim Distributor Farnell bestelltes Netzteil, habe auch schon probiert, über ein dediziertes USB-auf-Mini-USB-Kabel den Pi vom Powered Hub mit zu versorgen (KEIN Backpower!). Macht keinen Unterschied.

Zudem sollte der RPI Made in UK sein (die Chinaversion stürzt gerne mal ab).

Das halte ich für ein Gerücht. Im offiziellen Pi-Forum wurde auf meine explizite Nachfrage hin bestätigt, dass es im USB-Bereich keinerlei Unterschied zwischen den verschiedenen Pi-Revisionen gibt; ich rede hier vom Modell B, das Modell A hat natürlich nur einen USB-Port, dahinter aber die gleiche Firmware.

Nach 9 Stunden wo alle 3 Sekunden der Datentransfer gemessen wird gibt es aktuell keine Auffälligkeiten.

Testet Ihr auch wirklich das gleiche Szenario wie hier in diesem Thread besprochen, also als Vorlage floos Skripte zur Messung der Segmentauslastung?

Ansonsten läuft das System nun länger als 12 Stunden ohne Probleme.

Das hat nichts zu sagen, siehe auch floos letzte Postings mit den initialen Jubelmeldungen, dass der neue Stick stabil läuft, wo nach einem Tag die Schnittstelle doch wieder aufgegeben hat.

[NoGi]

In welchen Abständen ist das bei euch passiert?
[schnippel]
Ansonsten läuft das System nun länger als 12 Stunden ohne Probleme.

Wie ihr meinen bisherigen Artikeln auch schon entnehmen könnt, betreibe ich meinen Pi an
einem "6 port USB3.0 + 2port charging hub" der 2 A an den Ladeports liefern kann.

Ich überwache bei jedem Minutenlauf der "fLoo" scripts ob sich eine Zeile mit "timed" im mediaclient.log findet.
Bei Übereinstimmung wird de Pi einfach durchgebootet.

Leider habe ich letzte Woche mein /var/log Verzeichnis aufgeräumt und dabei auch die gepackten mediaclient.log.bz2.x gelöscht.
Ich kann also nur folgendes liefern:

Code: Alles auswählen

root@NoGiPi:~# zgrep timed  /var/log/mediaclient.* 
2014-03-29 06:03:26 [13360] timed out reading confirmation from mediasrv
2014-03-29 06:03:37 [13372] connection to driver service timed out
2014-03-29 06:03:47 [13372] connection to driver service timed out
2014-03-29 06:03:57 [13372] connection to driver service timed out
2014-03-30 21:32:21 [4432] timed out reading confirmation from mediasrv
2014-03-30 21:33:11 [4456] connection to driver service timed out
2014-03-30 21:33:21 [4456] connection to driver service timed out
2014-03-30 21:33:31 [4456] connection to driver service timed out
2014-03-30 21:33:41 [4456] connection to driver service timed out
2014-03-30 21:33:51 [4458] connection to driver service timed out
2014-03-30 21:34:01 [4458] connection to driver service timed out

Ich melde mich wieder wenn ich das nächste Mal ein ungewolltes "Loch" in meiner Auslastungskurve habe.

-NoGi

[rumble_ef]

Jetzt muss ich euch aber mal HART auf die Füsse treten, wenn ihr testet, dann Realitätsnah. Also entweder mit einem "Handy Ladegerät" oder einem powered USB Hub. Ein stabilisiertes Labornetzteil... echt mal, das kostet mal leicht das 10-fache vom Rest.

Stichwort: Reproduzierbarkeit. Was nützt ein Testaufbau mit Geräten, deren Parameter man nicht exakt kennt, oder die nicht konstant sind (sowohl zeitlich als auch mit einem "identischen" zweitem Gerät).

[Bino]

Moin

Wird dieses Plugin auch irgendwo zur Verfügung gestellt ?? kann es nicht finden

[NoGi]

In welchen Abständen ist das bei euch passiert?
[schnippel]
Ansonsten läuft das System nun länger als 12 Stunden ohne Probleme.

Wie ihr meinen bisherigen Artikeln auch schon entnehmen könnt, betreibe ich meinen Pi an
einem "6 port USB3.0 + 2port charging hub" der 2 A an den Ladeports liefern kann.

Ich überwache bei jedem Minutenlauf der "fLoo" scripts ob sich eine Zeile mit "timed" im mediaclient.log findet.
Bei Übereinstimmung wird de Pi einfach durchgebootet.

Leider habe ich letzte Woche mein /var/log Verzeichnis aufgeräumt und dabei auch die gepackten mediaclient.log.bz2.x gelöscht.
Ich kann also nur folgendes liefern:

Code: Alles auswählen

root@NoGiPi:~# zgrep timed  /var/log/mediaclient.* 
2014-03-29 06:03:26 [13360] timed out reading confirmation from mediasrv
2014-03-29 06:03:37 [13372] connection to driver service timed out
2014-03-29 06:03:47 [13372] connection to driver service timed out
2014-03-29 06:03:57 [13372] connection to driver service timed out
2014-03-30 21:32:21 [4432] timed out reading confirmation from mediasrv
2014-03-30 21:33:11 [4456] connection to driver service timed out
2014-03-30 21:33:21 [4456] connection to driver service timed out
2014-03-30 21:33:31 [4456] connection to driver service timed out
2014-03-30 21:33:41 [4456] connection to driver service timed out
2014-03-30 21:33:51 [4458] connection to driver service timed out
2014-03-30 21:34:01 [4458] connection to driver service timed out

Ich melde mich wieder wenn ich das nächste Mal ein ungewolltes "Loch" in meiner Auslastungskurve habe.

-NoGi

Meld hätte editiert, aber das ging nicht mehr, so muss ich mich halt selbst zitieren.
Gestern war es wieder soweit:
2014-04-03 17:10:33 [12203] timed out reading confirmation from mediasrv
2014-04-03 17:10:43 [12215] connection to driver service timed out
2014-04-03 17:10:53 [12215] connection to driver service timed out
2014-04-03 17:11:03 [12215] connection to driver service timed out
root@NoGiPi:~#

Trotz heftigem Arbeiten durch UMKBW (mehrfach alle 12 Kanäle auf NULL) ist heute kein Problem aufgetreten.

[ externes Bild ]

-NoGi