Hohe CPU-Last duch JtG

[AllOlli]

Hallo, nachdem meine alten Posts nach einem Serverproblem jetzt alle unter bigotti5 (fragt den Server...) laufen, habe ich lange nix gepostet. Jetzt lass ich aber mal wieder meinen alten Bugbericht aufleben.

Seit dem letzten Mal habe ich WinXP neu installiert, es ist jetzt XPpro mit SP1. Ich streame mit JtG unter Dotnet-FX 1.1 mit der WinGrabEngine. Auch mit neuem System und neuem Jack stelle ich immer noch fest, dass die Anzeige der "Informationen"-Karteikarte beim Streamen dafür sorgt, dass die CPU-Belastung von 2-5% auf 5-30% ansteigt. Und dass nur, weil da live die Texte aktualisiert werden. Allein schon das Geflacker bei den Textfeldern für Audio-HTTP und Video-HTTP sieht so aus, als ob hier CPU-Zeit verbraten wird. Evtl. hilft es schon, wenn man die Update-Frequenz konfigurierbar macht...

[petgun]

Auch mit neuem System und neuem Jack stelle ich immer noch fest, dass die Anzeige der "Informationen"-Karteikarte beim Streamen dafür sorgt, dass die CPU-Belastung von 2-5% auf 5-30% ansteigt. Und dass nur, weil da live die Texte aktualisiert werden. Allein schon das Geflacker bei den Textfeldern für Audio-HTTP und Video-HTTP sieht so aus, als ob hier CPU-Zeit verbraten wird. Evtl. hilft es schon, wenn man die Update-Frequenz konfigurierbar macht...

kannst Du Dir vorstellen das das streamen selbst CPU-Last schluckt? Nimm mal pro7 (feste Datenrate) auf und vergleiche die CPU Last unter JtG mit der Wingrabengine und unter Ngrab/Wingrab(x)....dann kannst Du weiter spekulieren

cu,
peter

[AllOlli]

Das Streamen ist nicht für die Last verantwortlich. Die 2-5% Last beziehen sich auf bereits aktives Streamen (P4 2.5, nebenher laufen noch permanent ein Emule und ein Webserver), wenn die "Informationen" Karteikarte nicht angezeigt wird. JtG ist sehr ressourcenfreundlich, wenn man während des Streamens das Fenster minimiert oder irgendeine andere Karteikarte anwählt. Sobald man aber auf "Informationen" wechselt, wo die Ausgaben der WingrabEngine ausgegeben werden, schnellt die Last hoch und erreicht in den Peaks 30%.
Das Problem hatte NGrab vor 0.7.70 auch. In den neueren Versionen ist die Last beim Streamen viel geringer. Irgendwas hat der Programmierer meiner Meinung nach bei der Ansteuerung des Textfeldes geändert. Vielleicht schreibt Levi dem NGrab-Coder einfach mal 'ne Anfragemail, eventuell kennt der die Problematik.

[Levithan]

Das Problem hatte NGrab vor 0.7.70

Hatte nGrab eine grafische Ausgabe ??

Zum anderen liegt Jack momentan auf Eis. Es ist zur Zeit fraglich, ob es mit Jack weitergeht. Sollte es zum Close des Projekts kommen, werde ich die Gründe rechtzeitig bekanntgeben.

Levi

[petgun]

hi,

Zum anderen liegt Jack momentan auf Eis. Es ist zur Zeit fraglich, ob es mit Jack weitergeht. Sollte es zum Close des Projekts kommen, werde ich die Gründe rechtzeitig bekanntgeben.

wie kann ich da noch auf 'AllOlli' antworten.....ich hoffe, ich habe einen Albtraum !

cu,
peter

[AllOlli]

Auf Eis? Zuviel vorm Rechner gehockt und die Familie vernachlässigt. Auszeit nehmen! Aber doch nicht einfach wegwerfen!

Und: Ich blende die grafische Ausgabe nicht ein. Oben werden nur die Statustexte angezeigt. Die Last ist in beiden Fällen gleich hoch. Ich habe die Textfelder für AudioHTTP und VideoHTTP im Verdacht.

[petgun]

Das Streamen ist nicht für die Last verantwortlich. Die 2-5% Last beziehen sich auf bereits aktives Streamen (P4 2.5, nebenher laufen noch permanent ein Emule und ein Webserver),..... Problematik.

imho gibt's keine 'Problematik' und verstehe nicht was Du willst ? Du hast noch >60% CPU-Last Reserve und Emule und Webserver im Hintergrund laufen....was soll der Quatsch ?

Ich habe die Textfelder für AudioHTTP und VideoHTTP im Verdacht.

..dann nimm mal mit sserver/udrec auf...da gibt's _leider_ keine Ausgabe.

cu,
peter

[AllOlli]

Natürlich ist das bei mir kein Problem. Aber es gibt langsamere Rechner, die damit schon ein Thema haben. Außerdem bin ich selbst Informatiker, und daher wurmt es mich, wenn popelige Textausgaben das System stärker beanspruchen als DVB-Streams von 6Mbit/s, die fortlaufend auf Festplatte geschrieben werden.

[petgun]

Außerdem bin ich selbst Informatiker

?? und dann vermutest Du das Levithan eine suboptimale eigene Routine fuer eine simple Textausgabe geschrieben hat und damit so viel CPU-Last erzeugt ?

cu,
peter

[AllOlli]

NEIN, ich glaube, dass wieder mal die Windows-MFCs an allem Schuld sind, denn da ist jede zweite Funktion buggy. So wird quasi nirgends sinnvoll auf Nullpointer reagiert (man muss in C++ für alles Sicherheitswrapper einbauen). Thematisch passen gab es ewig lange Probleme mit Softscrolling.
Womöglich muss man nur irgendwas Merkwürdiges bei der Nutzung der Textfeld-Klasse anders machen und schon sinkt die Last auf quasi null.

[Levithan]

und dann vermutest Du das Levithan eine suboptimale eigene Routine fuer eine simple Textausgabe geschrieben hat und damit so viel CPU-Last erzeugt ?

zumal dieses Problem nur bei Dir aufzutreten scheint..

Auf Eis? Zuviel vorm Rechner gehockt und die Familie vernachlässigt. Auszeit nehmen! Aber doch nicht einfach wegwerfen!

Das hat andere Gründe, welche ich bei gegebener Zeit anbringen werde.

[AllOlli]

Hm. Dachte eigentlich, es müsse etwas breiter auftreten, da ich das System komplett neu aufgesetzt habe. Nutze WinXP Pro SP1 mit deaktivierter Luna-Oberfläche (also Look wie Win2K) und für die Grafik ATI Catalyst 3.7. Kann irgendjemand das Problem noch bestätigen? Wenn ich alleine bin: Geschenkt! Wäre aber sehr merkwürdig.

[Levithan]

Hm. Dachte eigentlich, es müsse etwas breiter auftreten, da ich das System komplett neu aufgesetzt habe. Nutze WinXP Pro SP1 mit deaktivierter Luna-Oberfläche (also Look wie Win2K)

ich auch...
Ich vermute, dass dort irgendein Patch von M$ fehlt. Ich habe vor einiger Zeit mal so ein Paket mit allen Patches seit XP1 installiert. Könnte mir schon vorstellen, dass es daran liegt.

[AllOlli]

Mal testen. Ich warte aber noch ein wenig ab, ob sonst jemand das Problem hat.

[DJ_Harty]

Wie kann man die grafische ausgabe in JTG anzeigen lassen, sie bild oben?