udrec: CPU-Last am PC bei 99%

Hi,

ich hab in letzter Zeit mit sämtlichen Images Probleme korrekte Aufnahmen zu machen.

Hier mal ein mein log von udrec:

Code: Alles auswählen

21:55:56 listening to any host on port 4000
21:56:31 to DBox: VIDEO 31341 16 0 1 vaaa 06e 078 079 07d
21:56:31 from DBox: INFO: forced TS-Mode
21:56:31 dbox is in spts mode, forcing -ts
21:56:31 from DBox: INFO: IP c0a80001 Port 31341
21:56:32 from DBox: PID vaaa 1 6e 78 79 7d
21:56:32 to DBox: START
21:56:32 Buffer Overflow Start: packet 2382848 read 0 max 5120
21:56:32 packet lost 2382873 0
21:56:32 Buffer Overflow Stop: packet count 2382926
21:56:33 2382926 packets lost
21:56:37 from DBox: ERROR: main() - TcpReceiver pthread_create: Interrupted system call

Dabei steigt die CPU-Auslastung am PC auf 99% an. Irgendwann steigt dann mein PC aus...

An was könnte das liegen?

Leider tritt das Problem sehr sporadisch auf. Ich kann den Fehler also nicht wirklich reproduzieren.

Vielen Dank im Voraus

slickwilly2000

Beitrag von **KeXXeN** » Freitag 4. November 2005, 22:40

Würde darauf tippen das deine Box öffter mal einen Restart braucht, worauf auch hinweisen würde das es eher sporadisch auftritt.

main() - TcpReceiver pthread_create: Interrupted system call

weist imo darauf hin das sich der Prozess auf der Box verabschiedet hat.

Das passiert bei mir auch wenn ich die Box zu lange an habe. Seit ich sie einmal am Tag neu starte, hab ich die Probleme eigentlich nicht mehr gehabt.

Das die Prozessorlast gen 100 geht ist dabei nur ein unschöner Nebeneffekt.

Danke erstmal für eine Antwort.

Ich konnte das Problem einigermaßen eingrenzen.

Ich hab mal "killall updstreampes" auf der Box ausgeführt. Da waren laut "top" noch einige Dinger drin. Nachdem ging's wieder.

Es scheint also so zu sein, daß udpstreampes nicht immer sauber beendet wird.

Evtl. könnte tonsel als Coder von udrec berichten, weshalb die CPU-Last da so in die Höhe geht.

Mein Computer schmiert mir da wegen Hitze-Problemen immer ab und lässt sich dann nicht mehr mit etherwake aufwecken, wodurch Timer-Aufnahmen unmöglich werden.

Vielen Dank im Voraus

slickwilly2000

Ähem - Hitzeprobleme sollte eine CPU niemals haben. Kühl die lieber mal besser, sonst ist bald Schluss mit lustig.

Du hast nicht zufällig ein 64-bit System am Start?

cu
Jens

Nein, ist ein AthlonXP 2800+. Der Kühler ist ne boxed-version.

Aber ich bekomm bei Volllast die Temperatur nicht in den den Griff. Und bei reproduizierbaren 70Â° C ist dann Feierabend.

@tonsel:
Könntest du mir sagen, weshalb die Prozessorlast da so in die Höhe geht? Du kennst dein Programm besser und ich hab jetzt nicht Lust den ganzen C# Code nachzuvollziehen.

Mfg
slickwilly2000

Beitrag von **tonsel** » Sonntag 6. November 2005, 09:40

21:56:37 from DBox: ERROR: main() - TcpReceiver pthread_create: Interrupted system call

Das deutet darauf hin, das der Speicher auf der DBox langsam knapp wird. Start udrec mal mit "-buf 8", dann braucht es nur noch halb so viel Speicher.

Warum der PC deshalb Amok läuft kann ich mir allerdings nicht erklären. Seltsamerweise kommen hier Unmengen an Netzwerk-Paketen an - Mehr als über eine 10MBit/s-Leitung überhaupt drüber gehen.

tonsel

tonsel hat geschrieben:
21:56:37 from DBox: ERROR: main() - TcpReceiver pthread_create: Interrupted system call
Das deutet darauf hin, das der Speicher auf der DBox langsam knapp wird. Start udrec mal mit "-buf 8", dann braucht es nur noch halb so viel Speicher.

Warum der PC deshalb Amok läuft kann ich mir allerdings nicht erklären. Seltsamerweise kommen hier Unmengen an Netzwerk-Paketen an - Mehr als über eine 10MBit/s-Leitung überhaupt drüber gehen.

tonsel

Das würde ja meine These bestätigen, daß noch mehrere Threads von "udpstreampes" auf der Box laufen, welche nicht sauber beendet wurden. Kann das sein?

Und dann ist ja kein Wunder, daß der Speicher knapp wird.
Der Schalter "buf" bewirkt ja eine Buffer-Änderung auf der dbox-Seite, oder?

Seltsamerweise kommen hier Unmengen an Netzwerk-Paketen an - Mehr als über eine 10MBit/s-Leitung überhaupt drüber gehen.

Kannst du mir das genauer erklären? Verstehe ich leider nicht. Was hat das mit meinem Problem zu tun?

Kann ich im Debugger irgendwie herausfinden, welcher Programmteil von udrec dafür verantwortlich ist, daß die Prozessorlast so in die Höhe geht?

Hab selber VisualStudio.NET als Studentenversion. Die entsprechenden Tools sollte ich also dafür haben.

Mfg
slickwilly2000

Beitrag von **tonsel** » Sonntag 6. November 2005, 13:17

Irgendwelche Änderungern auf der PC-Seite werden Dein Problem nicht lösen. Du musst dafür sorgen, dass auf der DBox kein Speicherüberlauf auftritt - am besten mit udrec -buf 8.

Die hängenden udpstreampes-Threads dürften nur eine Folge dieses Problems (Stichwort: Buffer Overflow) sein. Ebenso die viel zu hohen Paketzähler, die an den PC geschickt wurden und udrec aus dem Tritt gebracht haben.

tonsel

Hi,

ok, ich werde diese Option mal berücksichtigen und beobachten, was passiert. Werde mich dann nochmals melden.

Mfg
slickwilly2000

Hi,

hier bin ich also wieder, wie versprochen. Seit der Umstellung der Startparameter von udrec mit dem verkleinerten Buffer ist das Problem nicht mehr aufgetreten.

Die Folge der CPU-Last hatte also tatsächlich was mit dem mangelnden Speicher auf der Box zu tun, was zur Folge hatte, daß der 'udpstreampes'-thread nicht ordnungsgemäß beendet wurde.
Dies hatte scheinbar wieder zur Folge, daß die Paketzähler derart immens waren, was udrec selbst aus dem Tritt brachte und die CPU-Last in die Höhe trieb.

Aber alles letztenendes eine Folgeerscheinung... Nicht die Ursache selbst.

Danke an tonsel für den Tip!

slickwilly2000

Hallo,

jetzt muß ich mich doch nochmals zu Wort melden.

Mitterweile steigt die Auslastung von udrec sofort auf 100% an. Egal welchen Parameter ich verwende. -buf 8 bzw. -buf 16 liefern das gleiche Ergebnis.

Bei -buf 8 ist laut 'top' noch genügend freier Arbeitsspeicher vorhanden.

Dennoch steigt die Auslastung von udrec in sämtlichen Versionen sofort auf 100% an.

Liegt das evtl. am .NET Framework 2.0? Kann man udrec irgendwie debuggen, um zu schauen, was genau dafür verantwortlich ist? Oder trace bzw. debug-meldungen in den einzelnen threads ausgeben lassen?

Grüße,
slickwilly2000

Ich habe jetzt noch ein bisschen herum experimentiert.

Mit dem .NET Framwork 2.0 steigt die CPU Auslastung sofort nach Aufnahmebeginn auf 100%.
Installiere ich das .NET Framework 1.1 nach, verhält sich udrec ganz normal.

Der Fehler ist eindeutig reproduzierbar. Und das sogar noch auf 2 unterschiedlichen Rechnern. Wenn ich das .NET Framework 1.1 deinstalliere, taucht der Fehler wieder auf.

Dabei möchte ich noch anmerken, daß die aufgenommenen Streams fehlerfrei und ohne weiteres abspielbar sind.

Aber wo die Ursache liegt, ist mir nicht bekannt. Ich vermute eine kleine Änderung in den Assemblies der 2.0er Version.

Hat denn noch niemand diesen Fehler bemerkt? Evtl. könnte tonsel als Urheber von udrec etwas dazu sagen.

Grüße,
slickwilly2000

Beitrag von **jmittelst** » Sonntag 2. Juli 2006, 10:10

slickwilly2000 hat geschrieben:... Wenn ich das .NET Framework 1.1 deinstalliere, taucht der Fehler wieder auf....

.Net 1.1 ist Vorraussetzung. .Net 2.0 ersetzt 1.1 nicht, sondern ergänzt es nur. Also .Net1.1 immer drauf lassen, nicht deinstallieren.

cu
Jens

Beitrag von **tonsel** » Sonntag 9. Juli 2006, 16:25

Das Problem mit .Net2.0 ist mir durch mehrere User-Rückmeldung bekannt. Wenn ich udrec mit .NET2.0 übersetzte (z.B. aktuelles MS Visual Studio) ist das Problem bei mir nicht aufgetreten - Nur läuft die Exe dann nicht mehr mit .Net 1.1, die für JtG Voraussetzung ist. Ich kompiliere deshalb mit .Net1.1 solange bis JtG auf .Net2.0 umgestellt wird.

tonsel

jmittelst hat geschrieben:
slickwilly2000 hat geschrieben:... Wenn ich das .NET Framework 1.1 deinstalliere, taucht der Fehler wieder auf....
.Net 1.1 ist Vorraussetzung. .Net 2.0 ersetzt 1.1 nicht, sondern ergänzt es nur. Also .Net1.1 immer drauf lassen, nicht deinstallieren.

cu
Jens

Das sehe ich aber anders. .NET 2.0 sollte doch abwärtskompatibel sein. Alle Methoden des 1.0er Frameworks (zumindest deprecated) sind doch im 2.0er Framework auch enthalten. Ich sehe also keinen Grund, weshalb das nicht funktionieren sollte.

@tonsel: Weißt du, warum die Auslastung sofort auf 100% anspringt? Es muss ja einen Grund dafür geben...

slickwilly2000

slickwilly2000 hat geschrieben:...
Das sehe ich aber anders. .NET 2.0 sollte doch abwärtskompatibel sein. Alle Methoden des 1.0er Frameworks (zumindest deprecated) sind doch im 2.0er Framework auch enthalten. Ich sehe also keinen Grund, weshalb das nicht funktionieren sollte...

Mußt Du die Verantwortlichen bei M$ fragen. Ich kann nur sagen, das eine Parallelinstallation von 1.1 und 2.0 problemlos ist. Alles andere ist kontraproduktiv, zumindest für mich, weil ich schon ausreichend Software auf der HDD gesammelt habe, die beide Versionen erforderlich macht.
Auch M$ hatte bei Einführung von .Net 2.0 eine Seite, die Autoren auf Unterschiede hinwies. Kannst ja da mal suchen. Da wurde auch auf Inkompatiblitäten hingewiesen. Wird bei .Net 3.0 vermutlch nicht anders werden.

cu
Jens