GPU Auslastung im Benchmark nicht bei 100%

Der_NiP

Schraubenverwechsler(in)
Servus alle zusammen.

Habe bei Heaven Benchmark bemerkt, dass meine MSI 1070 Gaming G Maximal eine Auslastung von 85% hat. Woran kann das liegen ?

Danke schon mal und lG
 
CPU läuft auf 50 - 65 %, VSync ist nicht aktiviert :/

Klares CPU Limit.

Bei einer 4 Kern CPU, die von nur einem Thread (einem Programm, das nicht Multithreaded läuft) ausgelastet ist, wird nur 25% Auslastung (1 von 4 Kernen) angezeigt. Das muss man bei Auslastungswerten der CPU immer berücksichtigen. 100% CPU Auslastung schafft man - abgesehen von Spezialtools wie prime95 - eigentlich nie, obwohl eine Limitierung durch die CPU schon längst erreicht ist.
 
Klares CPU Limit.

Bei einer 4 Kern CPU, die von nur einem Thread (einem Programm, das nicht Multithreaded läuft) ausgelastet ist, wird nur 25% Auslastung (1 von 4 Kernen) angezeigt. Das muss man bei Auslastungswerten der CPU immer berücksichtigen. 100% CPU Auslastung schafft man - abgesehen von Spezialtools wie prime95 - eigentlich nie, obwohl eine Limitierung durch die CPU schon längst erreicht ist.

Prinzipiell richtig, aber ich überwache alle Kerne einzeln, und wenn ich Heaven laufen lasse, kann ich eine 470 mit einem Q9650(sic!) auf 100% füttern, ohne daß auch nur ein Kern nur kurz 80% Auslastung erreicht (durchschnittlich am stärksten gefütterter Kern um 60%)..

Da müsste schon stark unterbelichtete Hardware die 1070 füttern meines Erachtens, wenn das der Grund sein sollte.

@OP: Welche Settings genau im Heaven?
 
CPU Limit im Heaven ist aber ungewöhnlich....meine 5820k taktet nicht mal richtig hoch bei 15% Auslastung.
Extreme Preset geladen? Wieviele FPSScore hast du?
 
Was für eine CPU ist verbaut? Wenn es nach Profil geht...
...könnte das genau so gut ein Athlon 5350 sein, so viele Zahlen können da nicht passen. :ugly:

Versuch es mal mit dem Valley Benchmark
Wobei Valley sehr viel CPU-lastiger ist. Valley ist sogar so CPU-lastig, dass ich mit meinem System (übertakteter X6 + RX 480) quasi permanent im CPU-Limit hänge (IIRC - kanns gerade nicht testen), das ist viel heftiger als bei den meisten (modernen) Spielen.

Würde das Problem ignorieren und Heaven - das Ding kommt aus der Zeit der ersten Dx11-Grafikkarten! - einfach mal als nicht mehr relevant abstempeln. Wenn du irgendeinen Vergleichsbenchmarks für Balken haben willst oder einfach gucken willst, ob die Grafikkarte tut, nimm 3DMark und dessen Graphics Scores.
 
Wobei Valley sehr viel CPU-lastiger ist. Valley ist sogar so CPU-lastig, dass ich mit meinem System (übertakteter X6 + RX 480) quasi permanent im CPU-Limit hänge (IIRC - kanns gerade nicht testen), das ist viel heftiger als bei den meisten (modernen) Spielen.

Hmm echt ? Meine CPU langweilt sich da, und gurkt auf 20% Auslastung rum :ugly: Auf jedenfall ist es neuer und viel Grafiklastiger als der uralte Heaven Benchmark. Von daher kann es nicht schaden den mal zu testen.
 
Prinzipiell richtig, aber ich überwache alle Kerne einzeln, und wenn ich Heaven laufen lasse, kann ich eine 470 mit einem Q9650(sic!) auf 100% füttern, ohne daß auch nur ein Kern nur kurz 80% Auslastung erreicht (durchschnittlich am stärksten gefütterter Kern um 60%)..

Wenn ein Prozess auf einem Kern läuft und auch nur kurz unterbrochen wird (z.B. durch IO oder warten auf die GPU) wird sie sofort zu einem anderen Kern springen. Dadurch verteilt sich die Last optisch zwar auf alle 4 Kerne, jeder Kern mit 25% Auslastung, de fakto wird sie aber weiterhin nicht parallel ausgeführt, d.h. die Anwendung wäre auf einem Kern genauso schnell.

D.h. man sieht im Taskmanager nicht klar, wenn eine Single-Threaded Anwendung am Limit angekommen ist. Um das zu sehen, muss man sie auf einen Kern binden, was im Taskmanager mit ein paar Klicks zu machen ist.

Hmm echt ? Meine CPU langweilt sich da, und gurkt auf 20% Auslastung rum :ugly: Auf jedenfall ist es neuer und viel Grafiklastiger als der uralte Heaven Benchmark. Von daher kann es nicht schaden den mal zu testen.

Wie gesagt, 20% ist nicht unbedingt "rumgurken", wenn die Anwendung nicht multithreaded ist. Das ist dann sogar ziemlich nah am CPU Limit.
 
Eigentlich braucht man sich die CPU-Last nie anschauen. Egal wie die Last auf die Kerne verteilt ist. Am Ende sieht man sowieso nur das Multitasking von Windows.

Graka nicht voll ausgelastet: CPU zu lahm um genügend Daten für die Graka vorzubereiten. VRAM/RAM übervoll oder ein künstlicher Limiter (sync jeder Art oder Frame-Limiter/Engine-FPS-CaP) gesetzt.

Und wenn man es ganz schlecht getroffen hat, dann ist die GPU nicht richtig angebunden, weil sie nicht richtig im Slot sitzt oder ein anderer Defekt vorliegt. Dann ist es ein Bandbreiten-Limit.
 
Wenn ein Prozess auf einem Kern läuft und auch nur kurz unterbrochen wird (z.B. durch IO oder warten auf die GPU) wird sie sofort zu einem anderen Kern springen. Dadurch verteilt sich die Last optisch zwar auf alle 4 Kerne, jeder Kern mit 25% Auslastung, de fakto wird sie aber weiterhin nicht parallel ausgeführt, d.h. die Anwendung wäre auf einem Kern genauso schnell.

D.h. man sieht im Taskmanager nicht klar, wenn eine Single-Threaded Anwendung am Limit angekommen ist. Um das zu sehen, muss man sie auf einen Kern binden, was im Taskmanager mit ein paar Klicks zu machen ist.



Wie gesagt, 20% ist nicht unbedingt "rumgurken", wenn die Anwendung nicht multithreaded ist. Das ist dann sogar ziemlich nah am CPU Limit.

Wenn ich mir das im Ressourcenmonitor ansehe, habe ich heaven mit um 21 Threads, die in der Summe nur selten auf 25% Peaken und svchost, die mit meist etwas über 30 Threads nur selten auf 25% peakt.

Zurückgestellte Dienste und Prozeduraufrufe liegen dabei unter ein Sück je Sekunde im Schnitt auf der CPU und fressen dabei 0,05%CPU-Zeit im Schnitt.

Ich kann's nicht wirklich sagen, aber ich glaube nicht recht, daß hier ein Kern am Anschlag läuft.
 
bf3_2012_07_01_16_39_f7rr8.jpg

bf3_2012_07_01_17_43_ckxom.jpg

Da läuft auch kein Kern auf 100%, und trotzdem gehen die FPS mit wenn ich den Takt der CPU anziehe. Folglich ist es ein CPU-Limit.

Ihr beobachtet das Multitasking von Windows. Startet doch mal Prime95 mit einem Worker.

Du erwartest:
primetvu8j.jpg

Aber Windows macht:
cpu-limit_ein_thread_3kjcs.jpg

Und trotzdem ist es ein uns das selbe CPU-Limit.
 
Nein, ich weiß es nicht besser. Aber ich sehe einen Unterschied darin, daß meine Argumentation, daß eine Threadgruppe, die nur selten überhaupt die Dimension erreicht, daß sie einen einzelnen Kern auslasten könnte (also auf 25% nur selten peakt) nicht in der Lage sein könnte, einen einzelnen Kern auszulasten, wenn er denn mal an der Reihe ist. Deshalb konnte ich mit Deiner Antwort nichts anfangen. Obendrein hatte ich nur die BF-Screenshots gesehen.

Daß über 20 Threads mit einem dutzend Töchtern ruckeln und den Kern dicht machen, wenn ich sie auf einen einzelnen Kern nagele, scheint mir hingegen eher möglich.

Aber trotzdem, besser weiß ich das nicht. Entschuldige bitte meinen schlechten Stil oben, habe das heraus genommen.
 
Zuletzt bearbeitet:
Wie gesagt, am besten man bindet einen Prozess an einen Kern (engl. Windows: TaskManager->Details->Set Affinity). Dann sieht man perfekt, wie sehr ein Prozess einen Kern auslastet - natürlich ist die Aussage nur dann relevant, wenn der Prozess Single-Threaded ist. Aber immerhin.

Alles andere ist tatsächlich Kaffeesatzleserei. Denn wenn ein Prozess zwei Threads verwendet, der eine die Leistung eines Kerns zu 20% auslastet, der andere aber zu 100% (und damit am CPU Limit liegt), dann hast Du bei zwei Kernen dennoch nur eine Auslastung von 120% / 2 also 60% pro Kern. Sieht ja mal harmlos aus, oder?

Um ein CPU Limit nachzuweisen, ist die beste Methode, die Frequenz der CPU zu ändern. Wenn ich die Frequenz der CPU um 10% ändere und damit eine Änderung der Leistung von mehr als 5% erreiche, dann bin ich schon recht nah am Limit, wenn die Änderung gar knapp 10% ist, dann bin ich voll im Limit.
 
Zurück