Singlecore Turboproblem (nicht nur) beim Haswell-E

Natürlich wird skylake-e das Problem nicht mehr haben. Das ist doch gerade das Ziel von speedshift...


Intel hat erkannt, das dass hochtakten zu lange dauert und das verwalten des energiemanagements über das OS nicht gut funktioniert. Beides wird sich ändern.

Das langsame hochtakten ist doch aber nur der Auslöser, nicht das Grundproblem... Das Grundproblem ist, dass die CPU je nach Lastzustand gar nicht in den Turbo oder nicht in den vollen Boost geht...
Wie und was soll Speedshift daran ändern?

Das macht Speedshift:

Und was sagt uns das? -> es dauert eine Zeit, bis der Turbo greift. Was machst du also, wenn ne Singlethread Anwendung munter vom OS sehr sehr schnell zwischen den Threads hin und her geschubst wird?


Die Zeit zu ändern, bis der Turbo greift, ist nur die halbe Wahrheit... Es bedarf eigentlich viel eher einer Einstellung, die es dem Prozessor ermöglicht zu erkennen, ab welchem Punkt er die Taktrate hochziehen soll. Und das kann effektiv nur richtig gut IM Zusammenspiel mit dem OS passieren, denn schließlich ist es der Scheduler des OS, der die Threads verteilt.
Günstig wäre aus meiner Sicht, wenn das OS dem Prozessor vor dem rumschubsen sagen würde, wohin der Thread geschoben wird -> dann kann der Prozessor schonmal hochtakten und hat somit bis auf den Start der Last IMMER volle mögliche Power.
Oder alternativ, wenn die Einstellungen so aggressiv sind, dass der Prozessorcore bei jeglicher Last den Takt hochzieht.
Ich denke mal nicht, dass man sich von unterschiedlich taktenden Cores verabschieden wird -> denn das wäre die dritte Option, mit der man das Problem minimieren bzw. abschaffen könnte...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Natürlich wird skylake-e das Problem nicht mehr haben. Das ist doch gerade das Ziel von speedshift...


Intel hat erkannt, das dass hochtakten zu lange dauert und das verwalten des energiemanagements über das OS nicht gut funktioniert. Beides wird sich ändern.

Kann mich nur wiederholen. Intel ist das Problem bekannt, sonst gäbe es speedshift nicht und alles würde so weiter laufen wie gehabt. Herr lass Hirn regnen.
 
Also weil Intel jetzt Speedshift hat, können wir uns zurücklehnen und es wird schon :rolleyes: Ahh ja. So wird es werden...
Meine Fresse, ihr immer mit eurem Marketing blabla...

Nach der Grafik oben braucht Speedshift immernoch 5ms. 5ms wären 200 FPS in Games. Das heist, wenn da 200 Frames rauskommen, durchläuft der Hauptthread des Spiels mal schlapp 200 mal eine Schleife... Du kannst dir selbst ausdenken, wie oft der OS Threadscheduler die Threads eines Spiels zwischen den Hardwarethreads durchschubst und wie "gut" Speedshift in dem Fall funktioniert, wenn da 5ms Aufwärmzeit notwendig sind. :wall:
 
Günstig wäre aus meiner Sicht, wenn das OS dem Prozessor vor dem rumschubsen sagen würde, wohin der Thread geschoben wird -> dann kann der Prozessor schonmal hochtakten und hat somit bis auf den Start der Last IMMER volle mögliche Power.

Genau das halte ich auch für den sinnvollsten Ansatz. Wenn die Frequenz des shiftens gesenkt würde, wäre das auch schon hilfreich.

Und da die älteren CPUs alle kerne und nicht einzelne hochtakten, ist die Problematik dort quasi nicht spürbar.
 
Das Hauptproblem besteht ja darin, dass nicht mal P1 State erreicht wird bei Teillast was in ewigen Core geswitche Endet, sodass erst gar kein Turbo geschweige denn P0 zum Einsatz kommt. Wenn das in Zukunft komplett von der CPU gesteuert wird, erhoffe ich mir da schon Verbesserungen. Momentan ist es ja so, wenn X-Prozent Gesamtauslastung nicht erreicht wird, bleibt er unterhalb von P1. Schuld daran ist das OS.
 
Zuletzt bearbeitet:
Schon klar, aber wir wissen ja nicht, anhand was Speedshift den Spaß genau ermittelt... Wenn dort aber ebenso eine Aufwärmzeit vorhanden ist -> wie dem Diagramm zu entnehmen, muss das nicht sauber aufgehen, wie man es sich hier wünscht.
Das ganze auf "Last" pro Core zu ermitteln wäre eigentlich Grundvorraussetzung. Nur spuckt halt das OS drin rum, wenn es die Threads rumschubst... Das ist halt mein Bedenken an der Thematik.
 
Also weil Intel jetzt Speedshift hat, können wir uns zurücklehnen und es wird schon :rolleyes: Ahh ja. So wird es werden...
Meine Fresse, ihr immer mit eurem Marketing blabla...

Nach der Grafik oben braucht Speedshift immernoch 5ms. 5ms wären 200 FPS in Games. Das heist, wenn da 200 Frames rauskommen, durchläuft der Hauptthread des Spiels mal schlapp 200 mal eine Schleife... Du kannst dir selbst ausdenken, wie oft der OS Threadscheduler die Threads eines Spiels zwischen den Hardwarethreads durchschubst und wie "gut" Speedshift in dem Fall funktioniert, wenn da 5ms Aufwärmzeit notwendig sind. :wall:

Das ist doch kein Marketing Gag. Speedshift ist doch genau dafür entwickelt worden.

Das energiemanagment in der alten Form funktioniert bei immer breiteren CPUs nicht mehr. Bei haswell erst recht, da die einzelne Kerne unterschiedlich takten können. Soweit alles klar.

Und was mach speedshift nun besser? Zum einen taktet ein Kern nun in einem Bruchteil der Zeit hoch zum andere funktioniert das vom OS losgelöst.
Warum sollte Intel das nicht hinbekommen? Wenn nun die CPU merkt, dass dort singlethread Last gefordert ist könnten Kerne teilweise hochhalten bevor die Last kommt. Da gibt es viele Möglichkeiten.

Sowie der FSB zum flaschenhals wurde und ersetzt wurde, so ist das energiemanagment für moderne Prozessoren nicht mehr geeignet. Warum sollte man etwas etwas halbgares implementieren. Das ist eine Lösung für die nächsten prozessorgenerationen.

Eher lächerlich ist es zu unterstellen, dass speedshift nur bedingt funktioniert. Da unterstelle ich dir , dass du keinen Plan von prozessorentwicklung hast. Mal sehen wer recht behält.

Wobei es meine ich schon Demos gab wo man den Mehrwert bei tablets deutlich sehen konnte.
 
Wobei es meine ich schon Demos gab wo man den Mehrwert bei tablets deutlich sehen konnte.
In der Tat, bei meinem Surface Pro 4 gab es einen spürbaren Unterschied nach dem Update bei Touch Bedienung, und "wie schnell der Stift malt wenn man losschreibt"
 
Eher lächerlich ist es zu unterstellen, dass speedshift nur bedingt funktioniert. Da unterstelle ich dir , dass du keinen Plan von prozessorentwicklung hast. Mal sehen wer recht behält.

Wobei es meine ich schon Demos gab wo man den Mehrwert bei tablets deutlich sehen konnte.

Unterstell mir so viel du willst. Aber sinnvollerweise hättest du ja mal was zu den 5ms sagen können. Stattdessen kommt Marketingbla und leere Worthülsen...
Da brauch ich keine Demos für um das zu sehen... Und nein, ich habe mit Prozessorentwicklung nix am Hut. Aber mit Programmierung -> und denke schon zu wissen, wie sich A) der Threadscheduler verhält und B) kann ich durchaus 1+1 zusammenzählen. Da brauch es auch keine "Vergleiche" zu Tablets, wo ein Dualcore mit SMT drin schlummert und ein einziger Thread 25% Gesamtlast ausmachen kann... Witzig, das jetzt bei 12-16 oder noch mehr Threads zu bringen.

Also entweder hast du das Problem, welches dieser Thread anspricht nicht verstanden oder du willst es nicht verstehen. Mit schnellerem Hochtakten ist es eben nicht getan. Es ist bestenfalls die halbe Miete... Aber das sagte ich bereits. Erkär uns doch stattdessen einfach, wie Speedshift das Problem lösen soll?
 
Tagchen die Leute.
Ich betreibe ja noch Win7 mit meinem i7-5820K und habe das Problem auch schon beobachtet. Hatte früher im Thread ja auch schon erwähnt daß ich mich mit den Energieeinstellungen von Windows herumgespielt habe mit den Registry Einträgen wo man mehrere Optionen bekommt.
Zu einer Lösung hat das jedoch nicht geführt.

Mir war das Problem auch nicht so wichtig da die meisten Programme und Spiele die ich nutze sowieso von mehr als einem Thread gebrauch machen und die CPU dann taktet.

Vor ein paar Wochen ist mir jedoch dann etwas aufgefallen ... ich hatte mir vor über einem Jahr das Spiel Insurgency (Shooter basierend auf der alten Source Engine) zugelegt und damals noch auf meinem alten System gezockt. Dann hatte ich es eine Weile nicht mehr gespielt und irgendwann im Herbst wollte ich es wieder spielen mit dem neuen Sys. Dazwischen waren einige große Updates des Spieles.
Tja auf jeden Fall hatte ich mit sehr miesen FPS zu kämpfen und hatte keine Ahnung warum, denn alle anderen Sachen liefen wie immer super. Hatte ewig die letzten Patches in Verdacht und habe unzählige Einstellungen des Spieles hin und her geändert sowie die Grafiktreiber aktualisiert etc. Ich konnte das Problem sogar reproduzieren, am Testgelände des Spieles direkt nach dem Einstieg gibt es gleich eine Stelle wo man unter einem Hindernis durchkriechen muß. Sobald ich mich in die Richtung gedreht habe brachen die FPS von >120 auf ca. 30 ein. :eek:
Sogar mit niedriger Auflösung und niedrigen Details hatte ich da nicht mehr als ~ 40FPS. :hmm:
Lag also nicht an der Grafikkarte.

Nach einer Weile herumprobieren und beobachten habe ich gesehen daß die CPU die Kerne fast permanent auf 1200MHz hält da die Auslastung ja so gering ist. Die Source Engine nutzt gerade mal 2 (lt. den Entwicklern allerhöchstens 3) Kerne bzw. Threads. Und die werden fröhlich herumgeschubst und somit hatte kaum ein Kern eine hohe Auslastung -> Kerne takten nicht hoch.

Sobald ich auf Höchstleistung gestellt habe hatte ich permanent > 100FPS in egal welcher Szene.

Habe mir jetzt angewöhnt für dieses Spiel (mit dem ASRock OC Tool) zwischen Performance und Power Saving umzustellen. Das geht mit dem Tool mit einem Klick.

Ärgerlich ist es jedoch allemal. Ob Windows 10 (mit Threshold 2 / Build 10586) es so viel besser macht? Wenn man Eure Kommentare so liest eher nicht, oder? Wollte Windows 10 noch nicht installieren solange es mir keinen Vorteil bringt und da ich nicht ganz einverstanden damit bin daß MS die Datensammelwut gepackt hat. Man kann zwar vieles deaktivieren mit diversen Tools, aber ganz traue ich dem ganzen Win10 noch nicht so recht.

---

Die Problematik wird jedoch wohl immer prominenter denn wie fdsonne schon sagt kommt ja AMD dann auch mit Zen und 8C / 16T und in Zukunft geht es wohl damit weiter.
Ich sehe auch nur zwei Möglichkeiten, entweder das ganze zum Großteil die Hardware steuern lassen (funktioniert wohl am effektivsten, lässt aber vielleicht weniger Einstellmöglichkeiten/Eingriffe zu und die Software muß auch damit klar kommen daß die Hardware das macht) oder es muß die Software stark optimiert werden (was ja gerade bei CPUs nie so einfach/schnell geht.)
Letzteres hat ja in der Vergangenheit schon oft für Probleme gesorgt, Mehrkernunterstützung war der erste Schritt (Windows NT), mit Hyperthreading der nächste (Win2K hatte da ja noch so seine Probleme und erst XP kam damit besser klar). Auch AMDs Cool'n'Quiet hatte Startprobleme mit Windows und benötigte Treiber/Patches.
Kerne einzeln zu takten oder gar zu deaktivieren bzw. parken sowie Turbo und Funktionen wie EIST und Speedstep oder eben bei AMD Cool'n'Quiet und Turbo Core sind zwar alles innovative und tolle Technologien um Strom zu sparen, auf der anderen Seite werfen die aber auch Probleme auf.
 
Kleiner Hinweis, SMT/HT funktioniert erst seit Windows 7 respektive 2008 R2 richtig ;)
Vorher kannte der Threadscheduler schlicht keinen Unterschied, ob das nun SMT oder ein physischer Core war. Heist, der Scheduler hat nicht unterschieden, wohin er die Threads geschubst hat. -> mit dem teils massiven Nachteil, das eben zwei Leistungsfressende Threads auf einem Core nebst dessen SMT Part geschoben wurden und die Performance eingebrochen ist, obwohl noch genügend andere Cores bereit standen...

Hat nur damals keiner wirklich gemerkt, da eben zu Zeiten, wo XP und Vista aktuell waren, eben die CPUs im Desktopbereich noch idR keine Quadcores mit SMT oder noch breitere waren ;) Bei nem Singlecore mit SMT ists schlicht egal. Dazu kam durch den Core2 ohne SMT auch wenig Bedarf zu derartigen Optimierungen (bei Vista bspw.) -> erst mit Nehalem gibts wieder los und das war dann schon Win7/2008 R2 Zeit...
 
Nach einer Weile herumprobieren und beobachten habe ich gesehen daß die CPU die Kerne fast permanent auf 1200MHz hält da die Auslastung ja so gering ist. Die Source Engine nutzt gerade mal 2 (lt. den Entwicklern allerhöchstens 3) Kerne bzw. Threads. Und die werden fröhlich herumgeschubst und somit hatte kaum ein Kern eine hohe Auslastung -> Kerne takten nicht hoch.

Sobald ich auf Höchstleistung gestellt habe hatte ich permanent > 100FPS in egal welcher Szene.

Was passiert wenn du das Spiel auf core 0 fixierst und die Priorität auf Echtzeit stellst?
 
Unterstell mir so viel du willst. Aber sinnvollerweise hättest du ja mal was zu den 5ms sagen können. Stattdessen kommt Marketingbla und leere Worthülsen...
Da brauch ich keine Demos für um das zu sehen... Und nein, ich habe mit Prozessorentwicklung nix am Hut. Aber mit Programmierung -> und denke schon zu wissen, wie sich A) der Threadscheduler verhält und B) kann ich durchaus 1+1 zusammenzählen. Da brauch es auch keine "Vergleiche" zu Tablets, wo ein Dualcore mit SMT drin schlummert und ein einziger Thread 25% Gesamtlast ausmachen kann... Witzig, das jetzt bei 12-16 oder noch mehr Threads zu bringen.

Also entweder hast du das Problem, welches dieser Thread anspricht nicht verstanden oder du willst es nicht verstehen. Mit schnellerem Hochtakten ist es eben nicht getan. Es ist bestenfalls die halbe Miete... Aber das sagte ich bereits. Erkär uns doch stattdessen einfach, wie Speedshift das Problem lösen soll?

Bisher hatte ich einfach nicht die Muße auf den Blödsinn zu antworten. Ich meine als Moderator mit 30k Beiträgen kann man wohl erwarten das man sich mal wenigstens eine News zu dem Thema durchliest... Aber egal.

SpeedShift ist eine Kombination aus mehreren Verbesserungen. Jede für sich würde das Problem schon massiv verbessern gegenüber Haswell-E. Wie gesagt ist das Turbo-Problem, zwar auch bei vorherigen Generationen aufgetretten, aber längst nicht so massiv wie bei Haswell-E, eben durch die unterschiedlichen Taktungsmöglichkeiten der Kerne. Dieser Energiesparvorteil durch Haswell-E macht eben ein neues Energiemanagment notwendig.

Das Beispiel mit dem Tablet ist dehalb so interessant, da wie du bereits richtig erkannt hast es in der Regel nur ein 2 Kerner mit SMT ist. Wieviele Turboprobleme kennst du bei DualCores mit SMT? Und dennoch ist ein Vorteil derart spürbar. Das Hauptproblem ist also die Zeit die vergeht zwischen Idle bis Turbo. Warum soll ICH eigentlich nun wieder Beispiele nennen?

Selbst hier im Thread kannst du einiges ableiten. Hier zum Beispiel erkennt man, dass der Basistakt noch beim normalen Energiesparplan erreicht wird. Nur für den Tubro reicht es eben nicht mehr. Die Zeit bis zum Turbo ist riesig. Spiegelt sich auch sehr gut mit dem wieder was das Intel "Marketing" so erzählt:
2-630.445119497.jpg


Neben dem schnelleren Hochtakten hat man noch ein weiteren Punkt berücksichtigt. Die P-States wurden überarbeitet. Das Takten ist dynamischer und nicht so fix wie bisher.
1-630.575836371.jpg


Warum spielen die 5ms keine Rolle:
Ganz einfach, da beim kleinen Haswell oder bei allen anderen Prozessoren zuvor es auch nicht gestört hat. Warum soll es jetzt wo die ganzen P-States in einem 1/4 der Zeit durchlaufen werden es anfangen zu stören?

Ganz davon ab hast du immernoch nicht verstanden, was es bedeutet, dass das Managment nun der Hardware überlassen wird. Es ist ja schön, dass du das mit deinem Softwarehintergrund versuchst zu verstehen, aber mal eherlich es liegt doch auf der Hand. Haswell-E ist in der Lage einzelen Kerne zu takten, das Energiemanagment kann damit nicht umgehen, gerade auch weil es die Threads umherschubst. Das ist fast schon wie mit DX12. Intel hat das Problem an der backe und MS bewegt sich keinen Schritt. Nun nimmt man es am liebsten selbst in die Hand. Oben habe ich Beispiele aufgeführt wie das gehen kann z.B. extrem Simple mit einem größeren Delay bis wieder runtergetaktet wird. (da wird Intel sicher bessere Ideen haben)

Dazu passt dann auch diese Meldung wunderbar ins Bild.
Ich kann mir das Theater super vorstellen:

Intel: "Euer Energiemanagment ist scheiße"
M$: "Warum takten eure Kerne nun auch individuell?"
Intel: "Wollen Energie sparen, passt mal euer Managment an"
M$: "Nö, kein Bock. Sind schon mit Dx12 beschäftigt..."
Intel: "Na gut dann machen wir das zukünftig halt in Hardware. Müsst trotzem etwas anpassen."
M$: "Nö, kein Bock.
Intel: "Das müsst Ihr aber einbauen und gut is. Geht nicht anders."
M$: "Pffff, soviel Arbeit. Na das gibts dann aber nur mit Windows 10."
Intel: "Syklake war vorher auf dem Markt"
M$: "Keinen Bock. Nur mit Windows 10"

Die einzige große Frage ist vermutlich, warum Speedshift nicht vor oder mit Haswell-E kam. Entweder man hat das Energiemanagment von Microsoft unterschätzt. Wollte für den Nachfolger einen Mehrwert oder Performanceboost. Oder erst müssen Kerne einzeln takten können bevor man ein komplexes Energiemanagment integriert. Oder einfach eine Kombination aus allem.
 
Zuletzt bearbeitet:
Was passiert wenn du das Spiel auf core 0 fixierst und die Priorität auf Echtzeit stellst?
Hab' das mal ausprobiert. Auch auf einen Kern fixiert mit Prio Echtzeit taktet er nicht hoch. Hab das mit Afterburner und HWInfo dazu mal durchgetestet. Da sehe ich auch daß selbst die Grafikkarte nicht mal ordentlich hochtaktet wenn es die CPU nicht tut. Springt zwischen 800 und 1000 herum. Im Normalfall taktet meine GTX 680 auf 1257 MHz hoch und bleibt dort no matter what. Auf Höchstleistung macht sie das auch brav da sie genug von der CPU zu tun bekommt.
Wenn ich mehr Kerne dazu schalte dann steigen die FPS leicht, aber der Takt ist noch immer im Keller.

Bei vielen anderen Spielen passiert das nicht - z.B. BF4 - gut das nutzt auch viele Kerne - da taktet er brav hoch.

Für Insurgency und wo es mir halt noch negativ auffällt schalte ich aktuell manuell mit dem ASRock Tool um. Ist ein Mausklick und nicht weiter schlimm.

Mal sehen wenn ich wirklich mal Win 10 ausprobiere ob es dort dann besser ist. Aber Intel/Microsoft sollten da tatsächlich eine bessere Lösung finden. SpeedShift dürfte schon mal ein Schritt in die Richtung sein. Wäre jedoch nett wenn es für Haswell-E auch eine Lösung gibt.
 
@Bucho
Hast du mal ParkControl ausprobiert: http://bitsum.com/parkcontrol/
Dort lässt sich z.B. festlegen wie viele Kerne an bleiben sollen.
Ich habe dort 50% eingestellt, das reicht für den max Turbo (Stock 4.2GHz, oc 5GHz)
Zudem lässt sich die Frequenz Skalierung einstellen, ich meine verstanden zu haben, warum Intel kein Bus oc mehr zulässt.

parkcontrol_jpghosuw.jpg
 
@Phantomias88
Habe das Programm jetzt mal ausprobiert. Bringt zwar eine Änderung, aber im Endeffekt auch nicht den gewünschten Effekt.

Was ich jetzt jedoch gemacht habe ist die Energieeinstellungsprofile alle zurückzusetzen. Das hat auf jeden Fall geholfen. Ich habe definitiv davor (also bevor ich angefange habe das Phänomen zu beobachten bzw. zu bekämpfen) nichts da drin herumgestellt.
Jetzt takten die Kerne auch im Ausbalanciert Profil wieder hoch wenn sie müssen. Zumindest im Fall von Insurgency, reine Single Core Programme hab ich jetzt noch nicht getestet.
Trotzdem gibt es Unterschiede die bestimmt das Problem welches fdsonne und G3cko ein paar Posts weiter oben angesprochen haben aufzeigen.
Insurgency Training - Sicht auf das erste Hindernis zum unten durch kriechen gerichtet:
Energiesparen ~ 65-75 FPS schwankend.
Ausbalanciert ~ 80-90 FPS schwankend.
Höchstleistung ~ 95 FPS relativ konstant.

Sprich bei Anwendungen die jetzt nicht das System soweit auslasten daß der Takt permanent hoch gehalten wird und somit die CPU (und bestimmt auch GPU) fröhlich hin und her taktet und das OS die Last auch zwischen den Kernen/Threads hin und her schubst ist das Endergebnis schlechter. Und das wird wohl je mehr Kerne / Threads man hat häufiger ein Problem.
 
Bei mir sind es 1-2 Anwendungen wo es spürbar unrund läuft und ein manuelles Pinnen über den Taskmanager Abhilfe schafft. Bei allen anderen habe ich genügend Leistung über ein in jedem Fall zwingend erforderlicheres agressiveres Energiemanagment-Profil. Den Rest erledigt die Zukunft und eine höhere Auslastung der CPU.
 
Testen kann man es schön mit SuperPi und einem Kern. 1x fixieren oder Höchstleistung und 1x ganz normal. Genau den Unterschied sieht man dann auch in Spielen, die nur wenig CPU Last erzeugen.
 
Hallo,

gibt es das Problem noch, bzw gibt es mittlerweile eine dauerhafte Lösung? Ich überlege mir gerade einen 5820k, Mainboard und RAM kaufen. Ich hab aber keine Lust solche Probleme beim Zocken zu bekommen...

Gesendet von meinem Xperia Z5
 
Schlimmstenfalls Energiesparprofil auf "Höchstleistung" stellen und den "minimalen Leistungszustand des Prozessors" auf 5%, dann taktet mein 3930k problemlos hoch.
 
Schlimmstenfalls Energiesparprofil auf "Höchstleistung" stellen und den "minimalen Leistungszustand des Prozessors" auf 5%, dann taktet mein 3930k problemlos hoch.

Das Funktioniert. Was mich daran stört ist, das die CPU bei jeder Kleinigkeit auf Max Takt hochgeht und hin und her Taktet wie ne sau auf der Flucht. Das ist auch irgendwie nicht sinn der Sache. Aber so wie es aussieht ist es momentan die einzige Lösung
 
In letzter Zeit beobachte ich immer häufiger das mein 5960X im Idle kaum noch auf 1.2Ghz runtergeht.
Irgendwas beschäftigt ihn sowieso ständig, so das er fast dauerhaft auf 4.5Ghz läuft. Und das OHNE das ich im Windows rumgestellt habe. (Win10).
 
Thx. Ich schau mal ob das überhaupt die Ursache ist, weil viel Leistung zeigt der Rechner nicht^^
 
In letzter Zeit beobachte ich immer häufiger das mein 5960X im Idle kaum noch auf 1.2Ghz runtergeht.
Irgendwas beschäftigt ihn sowieso ständig, so das er fast dauerhaft auf 4.5Ghz läuft. Und das OHNE das ich im Windows rumgestellt habe. (Win10).

Das ist mir auch neuerdings in CoreTemp aufgefallen. Anscheinend ein Bug des Tools. Die tasächliche Gesamtlast laut Taskmanager liegt bei 1%. Das der Takt immer direkt auf Maximum springt hat aber kaum Auswirkungen auf den tasächlichen Verbrauch. Zwischen Stock und OC@4,5Ghz liegen bei mir gerade einmal 1-2 Watt im Idle.

Auch wenn Haswell-E seine kleinen macken mit diesem Bug hat betrifft das eher alte Anwendungen. Der 5820k ist deulich zukunftsicherer als ein 6700k, gerade mit OC.
 
Zuletzt bearbeitet:
Darauf will ich hinaus. Das Ding geht so fix in den Turbo, des es schwierig ist Problemchen zu finden :-)
 
@Phantomias88
Habe das Programm jetzt mal ausprobiert. Bringt zwar eine Änderung, aber im Endeffekt auch nicht den gewünschten Effekt.

Was ich jetzt jedoch gemacht habe ist die Energieeinstellungsprofile alle zurückzusetzen. Das hat auf jeden Fall geholfen. Ich habe definitiv davor (also bevor ich angefange habe das Phänomen zu beobachten bzw. zu bekämpfen) nichts da drin herumgestellt.
Jetzt takten die Kerne auch im Ausbalanciert Profil wieder hoch wenn sie müssen. Zumindest im Fall von Insurgency, reine Single Core Programme hab ich jetzt noch nicht getestet.
Trotzdem gibt es Unterschiede die bestimmt das Problem welches fdsonne und G3cko ein paar Posts weiter oben angesprochen haben aufzeigen.
Insurgency Training - Sicht auf das erste Hindernis zum unten durch kriechen gerichtet:
Energiesparen ~ 65-75 FPS schwankend.
Ausbalanciert ~ 80-90 FPS schwankend.
Höchstleistung ~ 95 FPS relativ konstant.

Sprich bei Anwendungen die jetzt nicht das System soweit auslasten daß der Takt permanent hoch gehalten wird und somit die CPU (und bestimmt auch GPU) fröhlich hin und her taktet und das OS die Last auch zwischen den Kernen/Threads hin und her schubst ist das Endergebnis schlechter. Und das wird wohl je mehr Kerne / Threads man hat häufiger ein Problem.
ICh frage mich gerade ob das wirklich die CPU betrifft oder evt. den PCI Express Stromsparplan.
Dieser lässt sich auch einstellen in den Erweiterten Energieoptionen.
Mit dem Profil Ausbalanciert steht dieser auf mittlere Einsparung.
Ich habe bei mir im UEFI eine Option die nennt sich "PCIE Gen3 max Power" dadurch geht der PCIE Bus nicht mehr auf PCIE 1.1 zurück sondern bleibt bei beiden GPUs bei Gen3 @ Gen3 (GPUz).

Allgemein ist es normal, dass der Turbo im idle sofort anspringt, dieser soll ja bei "Teillast" greifen bzw. Programme die nicht die volle Leistung in anspruch nehmen.

Um den Single Core Turbo zu verhindern reicht es Core Parking zu deaktivieren indem man 100% Einstellt.
Dadurch werden die Kerne nicht mehr abgeschalten (dunkelgraue Balken = Core aus) und es greift nur noch der "all Core" Turbo.
Wenn es mit Park Controll nicht geht, musst im UEFI CC6 (AMD) deaktiveren.
 
Zuletzt bearbeitet:
Darauf will ich hinaus. Das Ding geht so fix in den Turbo, des es schwierig ist Problemchen zu finden :-)

Das ist bei meinem kleinen 4790k auch so. Wenn ich Höchstleistung einstelle und das minimum auf 5% runterdrehe dann dreht er richtig am Rad. Gut dann habe ich immer im Single Core 4,7 Ghz anliegen aber dieses gespacke nervt mich richtig :)
 
Also kann ich getrost zu Haswell-E anstelle von Skylake greifen? Es geht mir nicht um Sinn oder Unsinn, ich habe einfach den Drang wieder was neues zu haben und ich brauche mehr SATA 600 Anschlüsse für meine SSDs, da reichen die 2 vom Z77 einfach nicht mehr aus ;). PCI-E 3.0, mehr USB 3.0 Anschlüsse und M2 dabei dabei schöne Nebeneffekte.

Ich erhoffe mir von den 6 Kernen einfach mehr Zukunftssicherheit. Mein 2600k hat mittlerweile über 4 Jahre hinter sich (nach einem Austausch) und er wurde dauerhauft mit 4 GHz betrieben. Die selbe Taktregion möchte ich beim 5820k auch erreichen und laufen lassen.
 
PCI-E hab ich nur theoretisch, da der 2600k nur PCI-E 2 beherrscht... Zusatzcontroller geht auch nicht, da meine Slots schon belegt sind... Einer durch meinen Genesis, 4 durch meine Graka mit dem MK-26 und einer durch meine Soundkarte.

Die Vernunft sagt mir auch dass ich noch warten sollte... OC geht übrigens bis 4,7 GHz bei 1,35v. Mal sehen, vielleicht lass ich es so. Danke für die Infos :)

Gesendet von meinem Xperia Z5
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh