ja, und mein Profil is aktuell....

.


Seh da aber keinen 3.4Ghz Prozi?

hab ja auch nicht den selben prozzi, sondern dasselbe "Problem": nur 50-70 % Auslastung beim encoden....mein System weicht ja auch ab von seinem, ich glaube deshalb, das is wohl ein "HT"-Technologie-Problem, das die Auslastung nicht auf 100% kommen kann, jedenfalls bei einem Rechenintensiven Prozess

.


Aber er hat ja mit dem zweiten Sys 100%, von daher muß man doch annehmen das der ProCoder multitheading beherrscht.

na, und dann wären da noch die anderen optionen: Virenscanner läuft mit, Speicher und Platte Fragmentiert, oder Treiberprobleme/-inkompatibilitäten

Auf jeden Fall sollte soweit geklärt sein, das weder 60& noch 100% Auslastung dem System irgendwie Vor- oder nachteile beschert, jedenfalls nicht besonders erwähnenswert

Nur Warum kommt das nicht auf 100%??
Ich für meinen Fall sage mir: einerseits habe ich noch ein wenig Auslastung Frei, und andererseits: Hauptsache das Ergebnis kann sich sehen lassen, hauptsache, es dauert halt net ewig.

Ich nehme an, Rambus arbeitet anders und ddrram wieder anders, da wird wohl auch das Problem sein, oder ??
Die Northbridge ??? Speichermanager....?

Mal kurz wieder reingschaut...
Doch!
Ein 2. mal den Procoder aus Edius heraus anwerfen, dürft ned gehen - ich hab' jetzt aber testweise mal als 2. Prozess ein Encoden mit TMPGEC angeworfen.

Ergebnis: die CPU-Auslastung geht auf 98-100% - und gleichzeitig verlängert sich die Encode-Zeit(-Prognose) im ProCoder von 2:00 auf 2:47 Stunden!

Ich interpretier' das jetzt so: würde TMPGENC nur die restlichen 30% (auf die fehlenden 100) beanspruchen, müsste die ProCoder-Encodiererei genau so schnell weiter laufen.......tut sie aber nicht.

Oder wie interpretiert Ihr das?

-----

Virenscanner gibt's ned - ist ein reines Videoschnittsystem. Platten nicht fragmentiert - bringen auch beim Kopieren gemessene ca. 30 MB/sec., Treiberprobleme schließ' ich aus.

-----

Wie gesagt bzw. zusammen gefasst:

• auf dem 3.0-Rambus-System geht der ProCoder bei HT auf 100%.
• Auf dem 3.4-800MHz-Dualchannel-System schwankts bei HT um die 70% (andere Leuts mit selber Konfig bzw. Canopus-SW haben dieselbe Erscheinung) - aber er encodiert schneller als das 3.0er-System (ca. 2:00 im Verhältnis zu 2:25) - trotz der dämlichen CPU-Anzeige.
• Wenn ich HT im BIOS abdrehe, geht die Auslastung auf 100% (encoded aber langsamer).
• Als ich im BIOS den "DRAM IDLE TIMER" auf 64T gedreht hab' - war die CPU-Auslastung überhaupt NULL(!) - aber encoded hat er brav (daher halt' ich von der CPU-Auslastungsanzeige ned viel).

Ich seh' somit, dass das 3.4er-System (nach Einschalten des Turbo-Modus) nun schneller ist, als das 3.0er/Rambus-System. Ich weiß weiters, dass er etwas schneller wäre, wenn ich ihm noch 1 GB RAM raus zupfen würde. Also ist eigentlich alles im Lot - außer der dämlich-schwankenden CPU-Auslastungsanzeige.

Heut' könnt' ich nix mehr testen - muss mir die Kylie in der Stadthalle geben...:D

MfG
Quintus

.


Danke für dein Mithilfe bei dem Mystirium.

Praktisch läßt sich also die Leistung die der TaskManager als frei anzeigt nicht benutzen. Somit ist die Leistung nicht vorhanden und der TaskManager zeigt eine falsche CPU-Auslastung an.


Mails an ASUS, könnte sein die haben Lust es zu debugen. Viel Glück!

nein, da beide 60-70 % bräuchten, die jetzt zu 50:50 aufgeteilt werden, sofern man das so sagen kann...d.h. der erste prozess wird zugunsten des zweiten prozesses begrenzt, und der zweite kann aber auch nicht auf volle Leistung kommen....

Wenn du mal 4-6 Filme encodest, zeitgleich, dann wirst du sehen, das alle Filme gleich viele fps haben, da wird also nichts bevorzugt oder vernachlässigt, somit ist es klar, das das auch mit 2 Prozessen so sein muss; Also 50:50

Die Sache zu beurteilen wird durch einen Umstand noch erschwert: wenn ich mich nicht irre, ist TMPGENC nicht dualprozessorfähig - dürfte also nur auf der 1. (virtuellen) CPU laufen - der ProCoder hingegen ist dualprozessorfähig.

Jetzt ist die Frage, was XP daraus macht...

Egal, wenden wir uns wichtigeren Dingen zu.

MfG
Quintus

Doch, tmpgenc ist smp fähig und flutscht daher mit hyperthreading besser.