CPU-Auslastung beim Encoden
 

Servus@all,

ich hab' vorgestern meinen RAM von 1Gb auf 2GB aufgestockt, jetzt fällt mir auf,

• dass beim Encoden mittels Canopus Procoder die CPU-Auslastung um die 59-69% schwankt!

Vor dem RAM-Ausbau stand sie permanent auf 100%. Die Zeiten fürs Encoden haben sich allerdings NICHT verschlechtert - das Encoden von 2 Stunden Film dauert nach wie vor ca. 4,5 Stunden (2-pass VBR, mastering-quality, 1 Filter).

Wie ist die eigenartige CPU-Auslastung erklärbar? Oder muss ich im BIOS noch die Timings tunen (momentan steht alles auf Automatic)?

Thx
Quintus


ASUS P4C800E-DL, 3.4 Northwood, 4x512 Corsair TwinX 2CL, HT on (2 virtuelle CPUs)

CPU-Auslastung
 

ich könnte mich jetzt irren
aber bei Speicherausbau ist es doch gewollt
daß die CPU-Auslastung sinkt!!!???

oder nicht!!!:confused:

Schlecht find' ich's ja nicht - aber verstehen tu' ich's nicht. Wenn der RAM die Daten ausreichend schnell liefert, müsste sich doch die CPU wegbuddeln....oder?

MfG, Quintus

warum deswegen sinkt doch nicht automatisch die
berechnungszeit 3,4GHz bleiben 3,4Ghz

Eben drum - wenn die CPU voll ausgelastet ist, müssten doch die CPU-Auslastung auf 100% stehen - so wie auch vor dem Speicherausbau.

Aktuell encodet er jetzt einen 2:11-Film und wird dazu ca. 4:25 brauchen (ist noch ned ganz fertig).

MfG, Quintus

beim encoden kommts nicht nur auf CPU sondern auch auf RAM an, vergessts nicht, dass da große datenmengen geschaufelt werden.
anscheinend is das sys damit beschäftigt die ganzen daten im ram hin und herzuschieben, dadurch kommt das sys nicht zu 100% zum ecoden. wäre ev. erklärbar durch größeren adressierungsaufwand der bei der menge an ram entsteht, glaub ich aber eher nicht.
schau mal nach wie schnell die rams überhaupt laufen, hast vielleicht verschieden schnelle riegel gemischt?

Nein - ich hab' zu den vorhandenen Corsair DIMM TwinX 1024-3200LL Kit (=2x512) ein ebensolches Pärchen dazu gesteckt (von eben hier).

Im BIOS hab' ich alles auf Automatik gelassen. Obwohl NRE bei dem Kit 2-3-2-6 angibt, hat MemTest86+ hier 2-2-2-6 ausgelesen.

Was ich nicht versteh': wenn er nur CPU-Auslastung von durchschnittlich 65% hat (vorher: 100%), so müsste das Encoden theoretisch um die Hälfte länger dauern ... tuts aber nicht! Mit rund 4,5 Stunden für 2:11-Film im 2-pass VBR und mit 1 Filter liegt er eh recht gut, d.h. die Verarbeitungszeit hat sich NICHT signifikant geändert - das Encoden dauerte auch vorher etwas mehr als die doppelte Filmlänge.

Quintus


Nachtrag: jetzt ist er fertig - für 2:11-Film waren es 4:24 - das ist fast exakt die doppelte Filmlänge.

Ich würde jetzt mal schätzen, dass die Ram-Anbindung beim P4 ein schnelleres bereitstellen der Daten verhindert und desswegen die CPU nicht mit 100% ausgelastet ist.
Bei 1GB war die Auslastung vielleicht auf zusätzliches Auslagern zurückzuführen.
Die Timings würde ich manuell setzen, ein paar Minuten könnte dass bringen, wenn wirklich die Rams der bremsende faktor sind.

Der Speed vom Ram oder der HD, hat keine Auswirkungen auf KompressionsSoftwares wie VideoCodec.
Die CPU-Auslastung wird im Bios festgelegt , daher kommt es aufs Bios an was dir Windows an ProzessorAuslastung anzeigt.

Ein 2Ghz Prozi sollte auf jedenfall Video-Echtzeit schaffen. Wenn ich dich richtig verstanden hab braucht dein 3.4, für 4min Film 2min zum encoden, dass passt schon so.

.

Das muß ich noch etwas genauer posten:)

Das stimmt so wenn die KompressionsSoftwares die einzige Anwendung ist und Ziel und Quelle eine andere HD ist oder du SCSI-Raid0 hast.

Ja, das wäre eine mögliche Erklärung - danke!

@ red 2 illusion: nein umgekehrt - für 2 min Film braucht er 4 min zum Encoden (von einem HDD-Strip-0 auf ein anderes). Das halte ich aber für OK, weil ich nicht CBR encode, sondern VBR / 2-pass / mastering quality(!) / 1 Filter.

Ein Videoschnittkollege mit selber SW und selber HW-Ausstattung bringt ähnliche Werte zustande, wie ich in der Zwischenzeit per Mail erfahren habe.

Thx
Quintus

Also ich würde da ganz unbedarft sagen. Wenn der Speicher grösser wird können grössere "Brocken" hineingeschaufelt werden.

Speicher hat länger was zu tun... CPU mehr Zeit zum "Nachdenken"(Idle) ;-)

12fps mit IEEE-1180 Referenc IDCT ist zu wenig, oder rechnest du mit double precision? Du mußt First Pass ~80fps und Second ~40fps haben somit ~26fps gesammt mit SSE-IDCT.

IDE-Raid0 bietet in dem Fall keine Beschleunigung nur beim sequentiellen kopieren von Daten ist es schneller(Benchmark). Versuchs mit zwei schnellen HD auf verschiedenen Controllern.

das is schon ok, 720 x 576, vbr, 2 pass, da schaffe ich auch "nur" 9-12 fps, also 2 std film sind in ca. 4.5 stunden fertig

.

Habs von einem P3 hochgerechnet.

Die pro-Mhz-Leistung vom P4 ist ein Witz!

Mit welcher Precision rechnet der Canopus Procoder 64bit-Float oder 128bit-SIMD oder was???

Ich hab' keine Ahnung - er hat aber eine Reihe von Qualitätsstufen und "mastering quality" ist nun mal die mit Abstand langsamste. Abgesehen davon leg' ich ja - wie bereits mitgeteilt - noch ein Farbfilter drauf.

MfG
Quintus

.


Wird wohl ein 64bit-IDCT sein, dann ist der Speed wieder im grünen Bereich :), genau gewußt hätte ichs denoch gern.

Ich lass' jetzt gerade auf einem anderen Rechner einen Film encoden - der schafft es ein klein wenig schneller - obwohl die CPU ein 3,0GHz ist und der Rechner 1GB RAM hat....*kopfschüttel*. Zum Vergleich:

• P4C800E-DL/3.4 Northwood/2GB Corsair ...... braucht für 132 min Film zum Encoden 266 min (das Doppelte + 2 min)
• ein P4T533-C/3.0 Northwood/1GHz 533-Rambus ..... für 104 min Film zum Encoden 204 min (= 4 min weniger als das Doppelte).

Ergebnis: auf beiden Maschinen läuft's ungefähr gleich schnell - auf der schwächeren sogar einen Tick schneller...

Da hätt' ich mir vom 3.4er-System ein bißchen mehr erwartet - ist auch jenes System, wo die CPU-Auslastung um die 65% schwankt. Da muss ich anscheinend doch mit den RAM-Timings herum testen (bisher steht alles auf "Automatic").

Hat jemand Vorschläge für BIOS-Settings zum CL2-RAM???

Thx
Quintus


Nachtrag: ich hab' jetzt im BIOS "RAM forced mode" (oder so ähnlich) auf "einabled" gestellt - jetzt schwankt es zwischen 68 und 77% (vorher 59-69%).

Timings: 2-2-2-5 - obwohl ich mir nicht sicher bin ob das der Intel-Chipsatz schafft, ich glaube aber dass garfield36 sein P4-Brett so betreibt. Ist auf jeden Fall das schnellstmögliche für P4 / Athlon XP. Ansonsten: 2-3-2-6, 1T Command (<- das macht auch "viel" aus).

Mit dieser Einstellung ist er etwas schneller geworden: für 102 min Video hat er 181 min gebraucht - mit der alten Einstellung hätte ich auf ca. 206 min geschätzt, d.h. ca. 25 Minuten eingespart :).

Die zackelige CPU-Auslastungskurve ist weiterhin vorhanden.

MfG
Quintus

sag - da bei videoencoding ja grosse datenmengen geliefert/geschrieben werden müssen:
hast du mal gecheckt wie es mit dem IDE lamperl aussieht?
ist(sind) die platte(n) villeicht überfordert/fragmentiert?
ich versuche beim encoden immer von einer platte(quelle) mit ziel eine andere platte zu verwenden
weil wenns beim encoden keine 100% cpu last hinbekommst "verschenkst" ja rechenzeit
lg
xpression

Das BIOS bietet mir an:

• DRAM CAS# latency
• DRAM RAS# precharge
• DRAM RAS# to CAS# delay
• DRAM Precharge delay
• DRAM Burst length...

.... 5(!) Werte, alles in Clocks anzugeben. Und zusätzlich gibt's noch einen DRAM Idle Timer - da gibts zwischen 0T, 8T, 16T 64T und Auto auszuwählen...
Was gehört jetzt wo rein?

------------

@ xpression: ich encode eh von einer HDD (Strip-0) auf eine andere HDD (Strip-0).

Genau das denk' ich auch.....mit ist nur nicht klar, wo der Flaschenhals ist.

Thx
Quintus

Nachtrag: ich hab's jetzt ausgetestet, indem ich 2 RAM-Riegel wieder rausgezupft hab' - mit 2GB ist er tatsächlich um ca. 5-8% langsamer als mit 1GB beim Encoden (bei ansonsten identen Einstellungen). Vermutlich braucht XP mehr Zeit für die Adressiererei.

MfG
Quintus

Inder Reihenfolge, in der es Dir CPU-Z sagt zB. Konkret:

DRAM CAS# latency 2
DRAM RAS# precharge 2
DRAM RAS# to CAS# delay 3
Cycle Time (TRAS): 6
DRAM Burst length: so gross wie möglich

DRAM Command Rate: 1T

Noch besser wäre:

DRAM CAS# latency 2
DRAM RAS# precharge 2
DRAM RAS# to CAS# delay 2
Cycle Time (TRAS): 5
DRAM Burst length: so gross wie möglich

DRAM Command Rate: 1T

Das sind alle RAM-relevanten Timings die mir bekannt sind. Was die chipsatzspezifischen betrifft, irgendwo nachlesen. Im Zweifelsfall: selber testen :D. Eine www.UltimateBootCD.com mit MemTest86+ (besonders Test 5 loopen) und Prime95 drauf geben Dir Auskunft über Stabilität, ohne dass Du Gefahr läufst Dein Windows zu zerschiessen.

Viel Erfolg und halt uns jedenfalls am laufenden!

.


Wie sieht dein Windows aus? hast es mit HT installiert? Versuch mal das älterste und ein neueres Asus-Mainboardbios mit und ohne HT. (Verwende nicht die letzten update und keine Beta-Bios von ASUS)


Das IDE-Raid-0 bringt nichts, könnte sogar die Bremse sein. Mach mit einem weiteren IDE-Controller folgende PlattenConfig:

-booten von primären Master am ersten Controller(CD als Slave am primären Master)
-Video lesen vom sekundär Master am ersten Controller
- Video schreiben auf den weiteren Controller

@ Root: danke - ich hab' mit diesen "schärferen" timings herum getestet: es sind ein paar Minuten drinnen, d.h. im Bereich von 5-10 Minuten Zeitersparnis beim Encoden eines ganzen Films.

@ red 2 illusion: Windows ist mit HT installiert, das Board hab' ich erst einige Tage, weil ich es in Garantie wegen defektem USB-Port tauschen musste - ist somit weitgehend aktuell (und BIOS daher nicht beta). Als RAID hab' ich ohnedies nicht das onboard-IDE-Raid genommen - es steckt ein Fasttrack Promise 100 drinnen - die Benchmarktests zeigen > 50MB/sec, also alles im Grünen. Natürlich hab' ich auch getestet, wenn ich vom Fasttrack auf die normale IDE encode - es ändert sich nichts.

Ich hab' in der Zwischenzeit mit anderen Canopus-Kollegen sowie mit einem Canopus-Produktmanager in den USA Kontakt aufgenommen - bei anderen Kollegen mit gleicher HW ist's genau so und der Produktmanager meint, das sei wegen HT erklärbar - wären es 2 echte Prozzis, dann wärs nicht normal. Seine Antwort liest sich so:

Zitat:

Being that it's a HyperThreading system, that sounds reasonable. HT just "squeezes in" instructions when there is idle CPU time. The faster machine has a faster memory bus, which probably means there's less idle time waiting for memory operations, therefore less can be "squeezed in." Then again, it might be that you're running into some other limiting factor. Still, I never expect HT processors to show 100% usage. Dual physical cores, yes, but not a single core.

Warum die Auslastung allerdings so "schwankt" - siehe hier (zum Vergleich hier das 533er-Rambus-System), ist nach wie vor ungeklärt.

Nachdem ich nun in den Einstellungen auf "turbo" gedreht und die timings verschärft hab', ist das 3.4GHz-System schon noch ein bißchen schneller als das 3.0GHz-System - ich denke, ich lass' es jetzt so und bin zufrieden.

Thx
Quintus

Ich möchte noch ergänzen, dass ich, weniger genau,
aber über die Kühlwassertemperatur doch recht merklich,
festgestellt habe, dass kein Windows den P4 mit HT derart belastet,
wie es Linux schafft.
Als einzigen konkreten Vergleich für die reine Rechenleistung
habe ich mit SETI festgestellt,
dass Linux (Suse 9.0 in diesem Fall) um ca 20% mehr Leistung bringt.

Es hängt also nicht nur von der Hardware ab...

Komisch ist ja nur, dass

• das 533er-System (P4T533-C mit 3.0 und HT) es schafft, den Prozzi zu 98-100% auszulasten,
• während beim P4C800E-DL - auch HT - die CPU-Auslastung um die 70% herum kräftig schwankt - siehe obige GIFs (Links).

MfG, Quintus

Da hat sich doch auch ein wenig die Prozessor-Architektur geändert.
Möglicherweise verdaut das nicht jeder OS-Kernel optimal?

.

Ja, genau die Bremse meine ich:lol: als Ultra100 läuft er bei mir schneller. (nur nicht beim Benchmark)


Die CPU-Usage in Windows macht mir keine Sorgen, die Anzeige stimmt sowieso bei keinem Board ;) Solltest doch noch ohne HT und Fasttrak einen Versuch wagen, mach noch ein posting.

Wenn ich mich nicht irre, sind es in beiden Fällen Northwoods...
Hmmmm..... also ich schaff' von dieser "Bremse" ein Canopus-Präsentationsprojekt in Echtzeit und ohne(!) wesentlichen Bufferverlust zu fahren, in dem 7(!) Videospuren und einige Audiospuren gleichzeitig vom Fasttrack gelesen werden - und das sogar von den langsameren 5.400ern. Wenn da beim Encoden nur EIN File gelesen wird, sollte das doch reichen...

> DRAM Burst length: so gross wie möglich

Da hab' ich noch nicht herum gedreht, die stand immer auf Automatik - vielleicht sollte ich da noch mal was probieren.

Eindeutiges Ergebnis meiner Tests ist aber, dass die Maschine mit 2GB um 5-8% langsamer ist als mit 1GB - anscheinend braucht XP für die Adressiererei mehr Zeit.

MfG
Quintus

Nachtrag: ich hab' jetzt testweise HT ausgeschaltet - die Auslastung der CPU geht auf 100%, die Temperatur der CPU ist auch höher - aber Encoden tut er langsamer: 2:14 anstatt 2:02 (mit HT).
Die scheint für die Würscht zu sein.

Quintus

.

HT wirst nur richtig los mit einer Neuistallation, ansonst bleibt der MPS-Kernl und der ist eine Bremse für SingelCPUs.


Die Fasttraks sind PersonalRaids und haben ein unglaublich geringes I/0-Limit. 4Platten-Raid0 liefern mit 4KB Blocksize Sequentell grade mal ~5MB/sec bei mir. Als U100 ~10MB/sec gesamt mit Software-Raid0.
Bei 80fps und DV-Video kommst mit dem Raid0 leicht über diese Grenzen, dann muß die CPU warten bis wieder Daten von der HD kommen.

Das RAM kann keine Daten liefern die nicht vorhanden sind;) Cacheing kann nur ausgeführt werden wenn I/0 Ressourcen frei sind.
Ich wage mal zu behaupten du brauchst einen besseren Contoller für deine HD. Hast nicht doch die Möglichkeit den Fasttrak als Ultra100 zu betreiben und dir in Win ein SoftwareRaid einzurichten. Am besten einen Kanal vom OnboardController und einen vom Ultra100 und schreiben auf den anderen OnboradController. Damit müßte mehr Leistung möglich werden.


Ein SATA2 oder SCSI Controller liefert die Leistung viel eher, du solltest mal einen Testen.

Sorry, aber ich glaub' das nicht: wenn ich - wie bereits weiter oben geschrieben - von dem Raid (Fasttrack 100 Ultra ATA/100 RAID Card) ein DV-Echtzeit-Projekt mit bis zu 7 Streams gleichzeitig abpielen kann, kann das Raid fürs Encoden keinen Flaschenhals darstellen (denk ich mal).

MfG
Quintus

So sehe ich das auch.
Aber mach Dir um ein paar % performance nicht solche Sorgen, in ein paar Wochen kommen schon die nächsten Technologien am Markt, dann wird Dein System wieder zum alten Eisen gehören und performance kostet Dich wieder Geld statt Tüftelei...

Das RAM ist in der Lage 20-100mal mehr Daten zu liefern als der Fasttrack, warum denkst du dann ans RAM?


Was macht er eigentlich mit nur einem RAM-Riegel? Ändert sich damit auch nichts, oder?

Da ist es dann essig mit Double-Channel :eek: ;)

.


Genau, wird aber keinen (wenig) Unterschied machen weil ihn der Fasttrak bremst, meine ich. Bug oder Defekt will ich aber auch nicht ausschließen. Die üblichen Verdächtigen wie Win, Treiber, Software hat er bestimmt schon selber geprüft.

Mach' ich mir eh' nicht - wenn ich aber diesem GIF glauben könnte, müsste bei 100% Auslastung der Film in 2/3 der Zeit fertig encoded sein.

Alle meine Tests haben bis jetzt - wenn überhaupt - nur wenige Minütchen gebracht - ich bin mittlerweile der Meinung, die Auslastungsanzeige bei HT ist ein Scha*. Oder der Prozzi teilt die Arbeit wirklich so gut auf die virtuellen Engines auf, dass der limitierende Faktor zwar da, aber trotzdem im Prozzi zu suchen (und damit nichts dagegen zu machen) ist.

Schließlich haben Canopus-Kollegen dieselbe Werte.

Ich kann aber mal testhalber das AVI auf die normale HDD legen und von dort weg encoden.

MfG
Quintus

.....und mit nur einem RAM auch noch.