So - hab' jetzt noch weiter getestet:

• AVI von Raid (Strip-0) auf normale HDD exportiert - knapp 30MB/sec.
• Encoden von "normaler" IDE ist weder schneller noch langsamer.
• Wenn man im BIOS 64T einstellt - läuft er zwar genau so schnell - aber die CPU-Auslastung steht überhaupt auf Null .... *grmpf*
• Mit fixer BR encoded ist er natürlich deutlich schneller - 105min Film ist in ca. 135min encoded
• Mit der Hälfte RAM (2x512 anstatt 4x512) hab' ich es ja schon probiert - Ergebnis siehe oben. Mit nur einem Riegel geht lt. Handbuch dualchannel nicht, hab' somit keine Lust, das auch noch zu versuchen.

Ich lass' es jetzt so.

Thx
Quintus

und das leben geht weiter...

es sei denn man versäumt es vorm Bildschirm....

In den Benchmarks ist der P4@3,4Ghz aber schon 5% schneller.

Der RAM-Test hätte Licht in die Sache gebracht. Ich vermute das sich durch DualChannel die Leistung eher verschlechtert beim encoden.

Schade, dass es dir die 5Minuten nicht wert ist, es herauszufinden.

A-DATA DIMM Kit Vitesta 1024MB PC4500 DDR CL3 (PC566) und ein Software RAID0 Array unter Windows 2K/XP bringen die technischen Voraussetzungen für Live MPEG4 Encoden. Die CPU ohne HT benutzen.

Nicht, dass ich zu faul gewesen wäre - aber was bringt mir die Info?

Angenommen, ich komm' drauf, dass er mit 512 MB schneller encodet - was tu' ich dann? Für den Videoschnitt die Riegel wieder rein und fürs anschließende Encoden wieder raus - das kann's auf Dauer ned sein...

OK, es kann sein, dass der Kauf des 2. GB der Corsairs ziemlich blöd war' - aber da muss ich jetzt durch (wer weiß, wofür's gut ist).

MfG
Quintus

Geht mir auch immer so, man kauft allzuschnell(e) Rechner die man gar nicht braucht.:lol:



Ist mir schon klar du willst primär deine Fragen beantwortet haben, praktisch dein Ding rausschneiden aber ich versuch noch mal:
Läßt sich die restliche ProziPower die lt. TaskManager vorhanden wäre, eigentlich nutzen?

Na genau dass ist ja die Frage, er will sie ja nutzen aber zum encoden nicht als leerlaufprozess.

einen zweiten Film parallel encoden....dann is straight 100%, also Nutzen lässt sich das schon

.


Wenn er die Leistung nutzen kann, liefert der RAM wohl die nötigen Daten dafür. Daher kann der nicht zu langsam sein.


Aber wir werden es nie erfahren, oder???



@DCS

Hast du bei dir das gleiche Prob?

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.