Archiv verlassen und diese Seite im Standarddesign anzeigen : Wahnsinn: Unterschied zwischen angezeigter und tatsächlicher Auslastung
minos5000
2005-02-02, 21:12:37
Das Prozessoren praktisch nie komplett ausgelastet werden ist klar, aber wie gering die Auslastung teilweise ist, ist doch hart.
Ich hab das mal gemessen beim Video in Divx codieren.
Auslastung wird von Windows klar mit 100% angezeigt und so verhält sich das System auch, aber die tatsächliche Belastung des Prozessor sind lächerliche 35% bei meinem Athlon.
Oder beim Video capturen, Auslastung laut Windows 70%, tatsächliche gerade mal 14%.
Und zum schluß noch der CPU Test1 vom 3DMark03: 48.6% maximale Auslastung und mehr kann man einen Prozzi mit nem Spiel ja wohl kaum fordern :down:
Würd mich zu sehr mal interessieren, welche Komponenten der CPU da bremsen und welche gar nix zu tun haben.
so long
sdgsg
2005-02-02, 21:16:45
Mal ne Frage: Woher weißt den das genau??? Haste ein bestimmtes Prog benutzt oder wie?
minos5000
2005-02-02, 22:19:01
Mal ne Frage: Woher weißt den das genau??? Haste ein bestimmtes Prog benutzt oder wie?
Jupp, nennt sich PerfWatch.
Das ham die Leute von der c't für die aktuellen Prozessoren gebastelt.
Guest
2005-02-02, 22:28:43
http://exxtreme78.bei.t-online.de/Pics/Forum-Pics/oldnews.jpg
:)
Du hast soeben entdeckt, wofür Hyperthreading gut ist und wie viele freie Ressourcen in der CPU noch für andere Threads/Tasks nutzbar werden mit Hyperthreading.
Aqualon
2005-02-02, 22:35:38
Das Tool gibt es z.B. unter http://www.withopf.com/tools/perfwatch/
Eine wirklich neue Erkenntnis ist es ja nicht, dass die Prozessoren die meiste Zeit Däumchen drehen und auf die Peripherie warten müssen (die Latenzen ausserhalb der CPU sind schließlich um ein zigfaches höher als in der CPU).
Aqua
Savay
2005-02-02, 23:13:53
nunja...mit dem tool kann man gut die effizienz einer bestimmten architektur beleuchten!
die anzeige von win ist ja mehr eine systemlast anzeige...während das tool mehr oder weniger die auslastung der recheneinheiten in der CPU abbildet :)
wenn man da auf 100% kommt mit seinem AMD hat man ja quasi die TMD erreicht...dann dürfte nen FX-55 z.B. in dem moment wirklich mal seine 105 Watt verbrauchen :wink:
also man könnte indirekt auch übger die temperatur gehen :biggrin:
maximAL
2005-02-02, 23:21:40
heisst also, um annähernd 100% zu erreichen, bräuchte man ein programm, das die verschienen einheiten des prozessors optimal parallel auslastet und obendrein noch komplett im cache läuft?
Wie sieht das denn bei Prime95 aus?
Savay
2005-02-02, 23:33:23
och seehr mager...liegt so bei 22% :cool:
edit: sorry hab mich vertan ich hab superPi gemessen ich dulli :rolleyes: ...die auslastung bei prime liegt bei mir so um das bisherige maximum! 49-53%
auf meinem A64 natürlich...DivX liegt hier ja auch höher als beim AthlonXP...ich hab da 44% auslastung beim encoden :smile:
edit2: superPI erzeugt weniger CPU-last als nen WMV9-HD vid! die liegen je nach auflösung bei max 23-32% ...schwanken aber auch stark
nen MPEG2-HD in 1080p liegt dank NV DVD decoder bei 8% ohne bei 44-46 :biggrin:
BlackBirdSR
2005-02-03, 00:40:46
heisst also, um annähernd 100% zu erreichen, bräuchte man ein programm, das die verschienen einheiten des prozessors optimal parallel auslastet und obendrein noch komplett im cache läuft?
nein.
Der Code und die Umgebungsvariablen sind nur ein Teil des Pferdefußes.
Auch innerhalb der CPU gibt es Engstellen und Kompromisse, die es nicht erlauben, die CPU zu 100% auszulasten.
Beim K8 wurde z.B viel Wert darauf gelegt, den Ausführungsteil besser zu versorgen (On Die Memory Controller, Caches etwas verbessert, 2 neue Pipelinestufen). Den Effekt kann man ja sehen.
Aachenmade
2005-02-03, 01:06:13
Kann mal jemand Messungen mit nem P4 und HT machen??
Würde mich mal interessieren wieviel mehr interne Auslastung der P4 dann hat. Man kann ja z.B. 2x Prime durchlaufen lassen und die beiden Prozesse auf die beiden logischen Prozis aufteilen...
Bye
Aachenmade
LOCHFRASS
2005-02-03, 03:34:44
burnP5 und burnK6 oder burnP6 parallel laufen lassen, das quaelt nen P4-HT so richtig -> http://www.forum-3dcenter.org/vbulletin/showthread.php?t=145355 :D
Mit dem Tool MaxP4 (http://www.withopf.com/tools/perfwatch/P4MaxPerf.zip) kann man die CPU-Last auf über 90% hochjagen (2x gestartet mit HT). Teilweise werden Spitzen von 100% erreicht.
Haarmann
2005-02-03, 09:52:06
100% Auslastung hat ne CPU immer dann, wenn irgendeine Komponente ausgelastet ist. Das schwächste Glied der Kette bestimmt eben die Leistung der Kette...
wuschel12
2005-02-03, 10:12:29
Ich habe bei 100 % Windows 91,X % bei dem Tool.
Kann mal jemand Messungen mit nem P4 und HT machen??
Würde mich mal interessieren wieviel mehr interne Auslastung der P4 dann hat. Man kann ja z.B. 2x Prime durchlaufen lassen und die beiden Prozesse auf die beiden logischen Prozis aufteilen...
Bye
Aachenmade Vergleichswert für P4 ohne SMT (aus einem Thread von 2003 - old news halt, dieser Thread..): http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&postid=1232010#post1232010
Mit BurnK7 kommt man ebenso wie mit P4MaxPerf auf maximal ~85%. Ohne ist es deutlich weniger - siehe Link.
P4 ohne SMT:
http://www.forum-3dcenter.net/vbulletin/attachment.php?attachmentid=12984&stc=1
VooDoo7mx
2005-02-03, 12:11:33
Sehr interessant.
Wenn man HT effektiv nutzt, könnte man einen P4 besser auslasten als einen K8.
Werde das mal umgehend beim Pentium-M testen.
BlackBirdSR
2005-02-03, 12:58:40
Sehr interessant.
Wenn man HT effektiv nutzt, könnte man einen P4 besser auslasten als einen K8.
relativ gesehen vielleicht.
Aber ob das insgesamt so viel mehr ist?
Es kommt ja noch das FrontEnd und der Rest des Systems dazu. Und wenn der P4 mal nicht aus dem Trace Cache schöpfen kann, gibts Saueres, besonders beim Prescott.
Leider nützen solche Lastprogramme wenig um die Werte auf Spiele oder normale Programme zu übertragen :(
Gassst
2005-02-03, 21:18:47
Habt ihr das Programm Toast probiert? (Hier: http://www.benchmarkhq.ru/english.html?/be_cpu.html)
Erzeugt bei mir 75-95% Last unter "High Priority" Einstellung.
och seehr mager...liegt so bei 22% :cool:
edit: sorry hab mich vertan ich hab superPi gemessen ich dulli :rolleyes: ...die auslastung bei prime liegt bei mir so um das bisherige maximum! 49-53%
auf meinem A64 natürlich...DivX liegt hier ja auch höher als beim AthlonXP...ich hab da 44% auslastung beim encoden :smile:
edit2: superPI erzeugt weniger CPU-last als nen WMV9-HD vid! die liegen je nach auflösung bei max 23-32% ...schwanken aber auch stark
nen MPEG2-HD in 1080p liegt dank NV DVD decoder bei 8% ohne bei 44-46 :biggrin:
Welchen test hast du denn gemacht? Den Small FFTs (Max. FPU-Stress?)
Savay
2005-02-04, 00:37:26
korrekt :smile: habs grad nochmal ausgeführt...liegt so ziemlich exakt bei 54%
tombman
2005-02-06, 00:42:09
normale Programme können froh sein, wenn sie 50% echte Last erreichen...
cpu burn war bisher der Spitzenreiter was Last angeht..
Eignet sich auch wunderbar um overclocks auf Stabilität zu testen.... aaber Vorsicht: it´s hot man ;)
Pentagrave
2005-02-06, 10:52:02
ich habe das auch mal getestet und habe wenn ich bei Sisoft sandra den cpu test mach komplette auslastung also 100%, da wird anscheinend gut getestet...
TheCounter
2005-02-06, 13:01:17
ich habe das auch mal getestet und habe wenn ich bei Sisoft sandra den cpu test mach komplette auslastung also 100%, da wird anscheinend gut getestet...
Stimmt, aber die 100% sind nur für wenige Sekunden (vlt. 2 Sekunden). Bei Prime 95 + HDTV Movie (Das läuft dann sogar noch flüssig :D) komm ich auf max. 54% Auslastung (Durchschnitt eher so 47-49%). Selbst wenn ich 2 Movies gleichzeitig encode + HDTV Movie am laufen hab komm ich nicht über 68% Auslastung (max.).
DiGiTaL
2005-02-06, 16:38:09
RC5-72 ist auf einem A64 krass!
CPU-Auslastung (mit PerfWatch) von über 98 %
t-brett
2005-02-06, 18:17:08
Hmm jo schon interessant.
Wenn ich Prime95 (in place FTTs), Winamp und Sandra mit Priorität hoch laufen lasse, dann bekomm ich dauerhaft 60% real auslastung bei einem t-bred b mit 256kb l2.
wenn ich dann bei sandra arthimetische rechnungen benchen lasse wird kurzzeitig eine spitze von 100% angezeigt (musik von winamp setzt dann aus).
Aber was mich wundert, bei den ganzen anderen Benchmarkprogrammen (3dmark01se), wenn ich da Prime95 eben im in place ftt laufen lasse, winamp dazu und eben zb 3dmark01, dann ist das benchmark ergebnis kaum schlechter also ohne p95 und winamp.
CPU auslatung aber weiterhin max 60% dauerhaft.
daraus lässt sich schließen, dass windows praktisch der aktiven anwendung im vordergrund (in dem fall 3dmark01) die kompletten resourcen von windows und geräte zukommen lässt. P95 steht praktisch hinten an, winamp läuft weiter da die 3Mb im RAM sind und das wohl zu vernachlässigen ist.
Die CPu kann ja ohne hyperthreading nichts gleichzeitig machen.
z.b wenn man in nem spiel ist (offline) und in windows geht, dann pausiert das ja.
So ich habe jetzt aber mal getestet, wie das ist wenn man in nem online spiel ist (zb wc3) welches ja nicht pausiert werden kann, und nebenher prime95 sowie nen 3dmark01 benchmark laufen lässt
dann müsste windows nämlich wc3 und dem benchmark (da im vordergrund) gleichviele resourcen zuteilen---
Also, ich habe nun Counter-strike und wc3 jeweils online in nem spiel gehabt, Winamp und prime95. Diese dann minimiert und 3Dmark01se gestartet und durchlaufen lassen. Jetzt hat der Sound von Winamp als ausgesetzt (d.h. das konnte er dann nicht mehr) aber der Benchmark lief einwandfrei.
Ein paar einbrüche hatte ich, aber immernoch rund 11500 Punkte (von normal so 14-15k)
Die Spiele liefen aber immernoch weiter ohne zu laggen oder so (war noch im Spiel). Die Auslastung jedoch blieb immernoch bei 60% mit vielen Spitzen bei 100%.
Also mehr geht einfach nicht, aber trotzdem ist der T-bred B leistungsstark genug, 2 Spiele gleichzeitig multiplayermäßig zu verwalten und noch akzeptable Benchmark ergebnisse zu bringen.
Die selbe situation mit P4 und HT hätte wohl 100% auslastung dauerhaft gebracht und die natürlichen 14-15k im 3dmark ohne sound stocker. die spiele wären wohl noch flüssiger gelaufen.
Mersenne Prime zieht sich selbst zurück, wenn die Rechenkraft woanders gebraucht wird, ist quasi wie BOINC, nur effektiver. ;)
tombman
2005-02-07, 02:37:24
RC5-72 ist auf einem A64 krass!
CPU-Auslastung (mit PerfWatch) von über 98 %
EEK, KRASS!!
Habs gerade auch probiert.... echt arg.
Danke für den Tipp, endlich ein A64 Vernichtungsprogramm ;)
BlackBirdSR
2005-02-07, 06:58:30
EEK, KRASS!!
Habs gerade auch probiert.... echt arg.
Danke für den Tipp, endlich ein A64 Vernichtungsprogramm ;)
Alles BS :P
Und das obwohl RC5-72 NUR die Integerpipelines benutzt
;D
Seit ihr sicher, dass euch das Perfwatch sowas wie die FU-Auslastung anzeigt.
Ich vermute ja eher, dass sowas wie die AUslastung des Frontends angezeigt wird.
GloomY
2005-02-07, 12:24:24
RC5-72 ist auf einem A64 krass!
CPU-Auslastung (mit PerfWatch) von über 98 %RC5 ist ein Algorithmus, dessen Implementation in winzige Caches passt. Du wirst dort keinen Unterschied zwischem einem Duron und einem Thunderbird feststellen, genausowenig zwischen einem Gallatin und einem Northwood. Die Speicheranbindung ist ebenso praktisch irrelevant.
Kein Wunder, dass dann die Ausführungseinheiten die ganze Zeit am Ackern sind...
Alles BS :P
Und das obwohl RC5-72 NUR die Integerpipelines benutzt
;D
Seit ihr sicher, dass euch das Perfwatch sowas wie die FU-Auslastung anzeigt.
Ich vermute ja eher, dass sowas wie die AUslastung des Frontends angezeigt wird.Da wären wir bei der Frage, wie dieses Programm technisch funktioniert. Auf der Perfwatch-Seite (http://www.withopf.com/tools/perfwatch/) steht:Um die Auslastung zu ermitteln, bedient sich PerfWatch der "Performance Monitoring Unit" (PMU) des Prozessors. Beim Pentium 4 zählt das Ereignis "Uops Retired", beim Athlon, Duron und Opteron das Ereignis "Retired Ops", beim Itanium und Itanium 2 das Ereignis "Retired IA-64 Instructions" abzüglich "Retired NOP Instructions" und bei XScale-Prozessoren "Instruction executed".Man muss darüber diskutieren, ob das Beenden (retire) von Befehlen letztendlich so eine gute Metrik ist, denn gerade bei superskalaren Prozessoren sagt das nichts darüber aus, wie stark der Prozessor in einem Takt ausgelastet ist sondern nur dass er ausgelastet ist.
BlackBirdSR
2005-02-07, 12:35:52
Man muss darüber diskutieren, ob das Beenden (retire) von Befehlen letztendlich so eine gute Metrik ist, denn gerade bei superskalaren Prozessoren sagt das nichts darüber aus, wie stark der Prozessor in einem Takt ausgelastet ist sondern nur dass er ausgelastet ist.
Naja, wenn man das so zählt, ist es gar nicht so schlecht. (finde ich)
Nachdem der K8 z.B nur 3 Befehle pro Takt rauswerfen kann, würde es eh keinen großen Sinn machen, auf eine Auslastung aller Integer und FP-Einheiten zu hoffen.
Man müsste das halt vorher auch wissen ;)
Ich denke es wird oft davon ausgegangen, dass ein Wert von 85% eine 85%-ige Auslastung der gesamten CPU erzeugt.
Wie man an RC5-72 sieht, ist das eben nicht der Fall.
PS: Danke fürs Raussuchen der Erklärung von Perfwatch :)
GloomY
2005-02-07, 14:06:22
Naja, wenn man das so zählt, ist es gar nicht so schlecht. (finde ich)
Nachdem der K8 z.B nur 3 Befehle pro Takt rauswerfen kann, würde es eh keinen großen Sinn machen, auf eine Auslastung aller Integer und FP-Einheiten zu hoffen.Da hast du Recht. Jedoch sind es imho 3 x86-Ops/Takt, die in mehr als drei Mako-Ops zerlegt werden könnten.
Aber bedenke auch folgendes: Bei dieser Zählweise führt das dreimalige Ausführen von je einem Befehl pro Takt zu 100% Auslastung, während die Verarbeitung von diesen drei identischen Befehlen parallel (mit vorangeganenen 2 Takten Wartezeit z.B. auf Cache) zu einer durchschnittlichen Auslastung von nur 33% führt.
Ich hoffe mal, dass sich das wenigstens über eine längere Messdauer einigermaßen statistisch gleichverteilt, so dass der gewonnene Wert die obigen Abweichungen einigermaßen mittelt.
Man müsste das halt vorher auch wissen ;)
Ich denke es wird oft davon ausgegangen, dass ein Wert von 85% eine 85%-ige Auslastung der gesamten CPU erzeugt.
Wie man an RC5-72 sieht, ist das eben nicht der Fall.Ack.
PS: Danke fürs Raussuchen der Erklärung von Perfwatch :)Kein Problem. Das war das aller erste, was ich zu tun verspürte, als ich angefangen habe den Thread zu lesen...;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.