Prozessorauslastung beim Entpacken von Archiven

[Technischer Laie (Gast)]

Hallo Gemeinde,
nachdem ich hier im Forum schon oft erhellende Antworten auf meine 
Fragen bekommen habe, wende ich mich einmal mehr an euch.
Ich habe öfter große rar-Archive zum entpacken, z.B. 7GB, verteilt auch 
7 rar-Dateien. Laut Windows Taskmanager ist die Prozessorauslastung 
dabei immer zwischen 15% und max 20%. Zusätzlich habe ich in der Regel 
meine Satreceiverkarte am Laufen, die alleine zwischen 5% bis max 10% 
belegt. Die Frage ist: Ich verstehe nicht, warum das Betriebssystem 
(Win7) dem Winrar-Prozess nicht mehr Leistung zuteilt. Warum wird der 
Prozessor (AMD Athlon II, 6000) nicht einmal zur Hälfte ausgelastet? Ist 
vielleicht die Festplatte der begrenzende Faktor? Fragen über Fragen. Es 
würde mich freuen, wenn jemand eine Antwort oder Vermutung hätte.

Gruß Manne

[(prx) A. K. (prx)]

Sowas steht für Wartezeiten, z.B. auf Disk oder Netzwerk, wenn du die 
Auslastung eines Prozessor-Cores betrachtest. Denk ausserdem dran, dass 
RAR&Co i.d.R. nur einen Core verwendet. Wenn du also einen Quadcore 
haben solltest, dann wird RAR kaum über 25% Gesamtauslastung kommen.

[Technischer Laie (Gast)]

A. K. schrieb:
> Sowas steht für Wartezeiten, z.B. auf Disk oder Netzwerk

Das bedeutet also, dass die Festplatte dem Winrar nicht genug Daten 
liefern kann, um sie schneller zu entpacken. Sehe ich das richtig? Dann 
wäre ja vielleicht eine SSD das Mittel der Wahl.

[Olaf D. (Firma: O.D.I.S.) (dreyero)]

Hi Technischer Laie,

meinst Du die Processorauslastung gemittelt für alle Cores zusammen?
Dann ist Dein Entpacker nicht multitasking fähig.
Bei mir ist es zum Beispiel ein Octacore der in dem Fall genau 12,5%
Auslastung anzeigt.

Hat Deine CPU 4 Cores? Dann kommen 20% Auslastung doch hin...

Gruß

Olaf

Edit: Ich sollte vor dem Posten den ganzen Thread lesen :-(
Ich gehe jetzt besser ins Bett. Guts Nächtle...

[R. M. (rmax)]

Wenn das Archiv auf der Platte liegt, auf die auch die entpackten 
Dateien geschrieben werden sollen, sind wahrscheinlich die 
Kopfpositionierungszeiten der limitierende Faktor.

Die Platte muß ja ständig zwischen dem Archiv und den entpackten Dateien 
hin- und herspringen. Bei relativ kleinen Datenmengen fängt das der 
Plattencache des Betriebssystems und der Cache der Platte noch 
einigermaßen ab, aber bei 7GB sind die nach relativ kurzer Zeit am 
Anschlag und dann verhält sich das System u.U. so, als wäre gar kein 
Cache vorhanden.

[Technischer Laie (Gast)]

R. Max schrieb:
> Wenn das Archiv auf der Platte liegt, auf die auch die entpackten
> Dateien geschrieben werden sollen, sind wahrscheinlich die
> Kopfpositionierungszeiten der limitierende Faktor.
>
> Die Platte muß ja ständig zwischen dem Archiv und den entpackten Dateien
> hin- und herspringen. Bei relativ kleinen Datenmengen fängt das der
> Plattencache des Betriebssystems und der Cache der Platte noch
> einigermaßen ab, aber bei 7GB sind die nach relativ kurzer Zeit am
> Anschlag und dann verhält sich das System u.U. so, als wäre gar kein
> Cache vorhanden.

Bingo! Auf die Idee bin ich nicht gekommen. Werde ich morgen gleich mal 
checken. Vielen Dank!

[Amateur (Gast)]

Das entpacken ist, für heutige Prozessoren, keine besondere Belastung.
Das Hauptproblem wird sein, das ein zweifacher Datenstrom im Spiel ist. 
Logik hin oder her, es werden Daten gelesen, mit ihren Spur- und 
Sektoraktivitäten, während gleichzeitig im "Rückwärtsgang" das gleiche 
geschieht.
Bei einer Minidatei könnte das ohne Überschneidungen vonstatten gehen.
Bei großen Dateien "springt" die Kopfpositionierlogik aber zwischen den 
Positionen von zwei Dateien rum.

[Gerd E. (robberknight)]

Hast Du in dem RAR viele kleine Dateien? Dann kommt nämlich noch das 
Dateisystem dazu, welches beim Schreiben der vielen kleinen Dateien mehr 
Klimmzüge machen muss und dadurch noch mehr Kopfrepositionierungen 
braucht.

[c.m. (Gast)]

A. K. schrieb:
> Sowas steht für Wartezeiten, z.B. auf Disk oder Netzwerk, wenn du die
> Auslastung eines Prozessor-Cores betrachtest. Denk ausserdem dran, dass
> RAR&Co i.d.R. nur einen Core verwendet. Wenn du also einen Quadcore
> haben solltest, dann wird RAR kaum über 25% Gesamtauslastung kommen.

bei so großen archiven und regelmäßiger nutzung wäre es sinnvoll auf ein 
anderes, parallel arbeitendes, kompressionsprogramm umzusteigen - pbzip, 
pigz, pixz, oder wenn nur windows verwendet wird ein entsprechendes 
windows-programm.
das rockt dann so das man sich jedesmal einnässt vor freude :)

[Peter D. (peda)]

Technischer Laie schrieb:
> Ist
> vielleicht die Festplatte der begrenzende Faktor?

Mit Sicherheit.
Besonders, wenn es viele kleine Dateien sind.
Es könnte was bringen, wenn Du 2 HDD hast, das Archiv von einer HDD auf 
die andere zu entpacken.

[X2 (Gast)]

Peter Dannegger schrieb:
> Technischer Laie schrieb:
>> Ist
>> vielleicht die Festplatte der begrenzende Faktor?
>
> Mit Sicherheit.
> Besonders, wenn es viele kleine Dateien sind.
> Es könnte was bringen, wenn Du 2 HDD hast, das Archiv von einer HDD auf
> die andere zu entpacken.

Oder von einer SSD auf eine andere SSD ;-)

[Peter D. (peda)]

X2 schrieb:
> Oder von einer SSD auf eine andere SSD ;-)

Dürfte nichts bringen.
Bei der SSD entfällt die Zeit zum Umpositionieren auf einen anderen 
Sektor. Alle Zugriffe sind gleich schnell.

Bei USB-Sticks ist es sogar langsamer, wenn man von einem liest und auf 
den anderen schreibt.

[Peter II (Gast)]

Peter Dannegger schrieb:

> Bei USB-Sticks ist es sogar langsamer, wenn man von einem liest und auf
> den anderen schreibt.

hast du dafür eine Erklärung? Auch ein USB-Stick wird langsamer wenn man 
2 Dinge gleichzeitig auf ihm macht.

[X2 (Gast)]

Peter Dannegger schrieb:
> X2 schrieb:
>> Oder von einer SSD auf eine andere SSD ;-)
>
> Dürfte nichts bringen.
> Bei der SSD entfällt die Zeit zum Umpositionieren auf einen anderen
> Sektor. Alle Zugriffe sind gleich schnell.

Prinzipiell geht es doch nur darum das die Daten nicht schnell genug vom 
Medium in den Speicher und wieder zurückkommen. Wenn ich von einer SSD 
mit z.B. 400 MByte/s lesen und mit 250 MByte/s schreiben kann, bin ich 
doch trotzdem schneller als wenn ich bei einer guten Platte 150Mbyte/s 
schreiben und lesen kann.

Vorrausgesetzt natürlich der Rechner kann die Daten so schnell 
verarbeiten.

Peter II schrieb:
> Peter Dannegger schrieb:
>
>> Bei USB-Sticks ist es sogar langsamer, wenn man von einem liest und auf
>> den anderen schreibt.
>
> hast du dafür eine Erklärung? Auch ein USB-Stick wird langsamer wenn man
> 2 Dinge gleichzeitig auf ihm macht.

USB ist ein shared Medium, das heist alle USB Geräte teilen sich die 
Bandbreite. Jede ms kommt das nächste Device dran, wenn man nun 2 
USB-Sticks einsteckt (und sonst keine anderen USB Geräte eingesteckt 
hat) kommen diese immer nur abwechselnd dran. 1ms der eine, 1ms der 
andere. Wenn man nur einen einsteckt wird dieser jede ms abgefragt. So 
würde ich mir das erklären.

Das es langsamer wird mit nur einem Stick und 2 Tasks könnte dann vllt 
noch am Overhead der Mass Storage Class liegen.

[Peter II (Gast)]

X2 schrieb:
> USB ist ein shared Medium, das heist alle USB Geräte teilen sich die
> Bandbreite.
teilweise, 2 Ports teilen sich einen Hostdevice. Ein PC hat aber meist 3 
oder 4 Hostdevice. Und die Teilen sich nicht die Bandbreite.

[X2 (Gast)]

Peter II schrieb:
> X2 schrieb:
>> USB ist ein shared Medium, das heist alle USB Geräte teilen sich die
>> Bandbreite.
> teilweise, 2 Ports teilen sich einen Hostdevice. Ein PC hat aber meist 3
> oder 4 Hostdevice. Und die Teilen sich nicht die Bandbreite.

Das ist richtig, wobei ich drauf wetten würde das z.B. 2 Front-USBs am 
gleichen Rootport hängen.

[A. B. (funky)]

Neuere Versionen von WinRar sind übrigens Multicoretauglich

Ob deine Festplatte der limitierende Faktor ist, kannst du ja mal mit 
einem Benchmark Programm testen. Dort ermittelst du die maximalen 
Geschwindigkeiten und über die Windows ressourcenanzeige siehst du dann, 
wieviel MB gelesen/geschrieben werden, während du ein Archiv entpackst.