CPU-Auslastung beim Encoden

[xpression]

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

[Quintus14]

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...

Ansonsten: 2-3-2-6, 1T Command (<- das macht auch "viel" aus).

Was gehört jetzt wo rein?

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

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

weil wenns beim encoden keine 100% cpu last hinbekommst "verschenkst" ja rechenzeit

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

Thx
Quintus

[Quintus14]

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

[Root]

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 . 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!

[red 2 illusion]

.


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)

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

mit ist nur nicht klar, wo der Flaschenhals ist.

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

[Quintus14]

@ 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:

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

[Don Manuel]

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...

[Quintus14]

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

[Don Manuel]

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

[red 2 illusion]

.

Fasttrack Promise 100

Ja, genau die Bremse meine ich 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.