Singlecore Turboproblem (nicht nur) beim Haswell-E

[fdsonne]

Das mit dem Core Parking klingt in der Tat interessant... Wenn das so ist, wie dort im Link geschrieben, würde es auch den Leistungsverlust erklären... Die geparkten Cores benötigen sicher etwas Zeit um wieder hochzukommen. Genau so benötigt der Turbo wieder etwas Zeit um auf maximale Stufe zu gehen. Soweit mir bekannt, sollte die CPU auch die verschiedenen Turbostufen durchgehen anstatt gleich auf den maximalen Takt zu springen. Das Problem hierbei ist eher, das man das so ohne weiteres nicht messen kann. Auch wenn der Pollinginterval der Tools sehr kurz ist, ist das wohl immernoch zu lahm...

Ohne Hyperthreading tritt das Problem bei Haswell-E auch auf. Mit weniger Kernen (4 statt 6) tritt es bei Haswell-E noch stärker auf. Ist auch nachvollziehbar, weil dann ein Prozess wie SuperPi z.B. Von einem noch laufenden HWInfo noch öfter weggeschubst wird.

Also die Threads sollten sich rein vom Windows Threadscheduler nicht gegenseitig wegschubsen... Weder bei steigender noch bei fallender Coreanzahl!
Willst du sicher gehen, das das definitiv nicht passieren darf, dann stell im Taskmanager den Task des Benches auf "higher as normal" und schon hat dieser Task vorrang vor allen anderen, die idR als "normal" eingestuft sind...
PS: das Thread festpinnen geht auch über ein kleines mini Tool von Sysinternals (mittlerweile zu Microsoft gehörig) -> damit sparst du dir das nachträgliche im Taskmanager fixieren, da der Task von Anfang an mit dieser Affinität gestartet wird. Auch die Priorisierung sollte sich damit verändern lassen. Link dazu, siehe oben von mir!


Das SMT deaktivieren keine Verhaltensänderung bringt, verwundert mich bspw. auch nicht, da der Windows Threadscheduler seit Win7/2008R2 SMT als Feature von Intel CPUs kennt und möglichst sich dran hält, nie Last von in Summe mehr als einem vollen Core auf die beiden virtuellen Prozessoren eines Cores legt. Erst wenn die gesamt Load größer 50% über die ganze CPU liegt, wird SMT überhaupt in Anspruch genommen...
-> sehr gut zu beobachten bei Systemen mit minimaler Last, dort legt der Taskmanager diese minimale Last nur auf je einen Teil, nicht aber auf beide. Und wenn doch, dann ist die Summe beider zusammengehöriger Teile nicht größer 100% um möglichst nie in SMT Skalierungsprobleme zu verfallen.

Das sich hingegen bei Kürzung auf 4 statt 6 Cores eine Verstärkung des Problems einstellen soll, kann ich nicht glauben, da es völlig unlogisch wäre... Und damit jede andere CPU, die ebenso die Cores/Threads selbst unterschiedlich takten kann, ebenso von den Problem betroffen wäre. Was dann auf die aktuellen BD AMD CPUs genau so wie auf Haswell/Haswell Refresh zutreffen würde -> dort gibt es dieses Verhalten aber doch wohl nicht!?

 

[nemihome]

Ich habe gerade mal ein Spiel in Windows 7 getestet. Da wird auch nicht hochgetaktet. Das geht ja garnicht! 100% sind dann gleich mal über 120 Watt, weil er alle Kerne hochzieht. Mal Speedstep testen.

Edit: Speedstep führt zum selben Effekt. Testspiel ist ESO. Als nächstes mal Win 10 testen

Priorität hoch bringt ein wenig aber nicht genug. Da das Spiel über einen Launcher startet, kann man per Starkommando zwar die Zugehörigkeit des Launchers festlegen, aber nicht die des Spiels. Im Taskmanager geht es. Wenn ich das Spiel 4 virtuellen CPUs zuweise, läuft es gut.

Edit 2: Windows 10 verhält sich bei mir wie es soll. Ein Kern läuft dauerhaft auf Maxturbo, die restlichen nach Bedarf und 80 Watt Verbrauch nur CPU. Die Framezahl ist sehr gut.

Somit würde ich sagen bei Haswell-E ist es entweder ein Treiberthema (wobei ich nicht wüsste welcher) oder es liegt schlicht am Scheduler in Windows 7

 

[H_M_Murdock]

Ich kann mir schon vorstellen dass der Scheduler mit den"Per Core P-States" erst umgehen können muss um ein vernünftiges Ergebnis zu erzielen.
Dann scheinen die Probleme mit Haswell-E aber etwas ausgeprägter zu sein.

Ich konnte mit dem Sandy-E bei einem kurzen Test aller Windows Client Versionen ab 7 mit einem einzelnen Prime Worker keine Unterschiede im Turbo-Verhalten fest stellen. Egal ob fest gepinnt oder nicht, die CPU lief nie mehr als 4,2 GHz singlethreaded.
Jeweils mit dem Energiesparprofil "Ausbalanciert" getestet.

 

[nemihome]

Für Eso muss man scheinbar zwischen 4 und 6 virtuelle CPUs zuweisen - mehr wird langsamer. Die Framerate sackt dann von 76 auf 45 ab. Ist ja wirklich wie damals mit der Turbotaste. Nur muss man jetzt Kerne schieben.

Der Verbrauch liegt dann auch um 80 Watt (nur CPU) - bei 4,4 GHz geht das wohl i.O.

Man sieht auch schön, dass 6 virtuelle Kerne komplett aus sind - über die Stromsparmodi - im Taskmanager (keine Auslastungslinie). Die verbleibenden kümmern sich um die Hintergrundprozesse.

 

[H_M_Murdock]

Hast du mal beim zocken den anliegenden Takt beobachtet?

 

[nemihome]

Ich habe mir gerade mal Prozess Lasso runtergeladen. Damit kann man für jeden Prozess dauerhaft die Priorität und die Kernzugehörigkeit festlegen. Bis Windows 10 oder bis zu einer Updatelösung für Win 7 wird's das wohl tun.

 

[nemihome]

Hast du mal beim zocken den anliegenden Takt beobachtet?

Ja, geht auf einem Kern auf 4,4 und bei dem Rest nach Bedarf bei Windows 10. BeiWindows 7 ist es auch so, wenn man die Priorität erhöht und weniger Kerne zuweist.

 

[nemihome]

Wenn man die Framerate begrenzt (z.B. Auf 60 Herz) muss man wieder weniger Kerne zuweisen für maximale Performance. Ein Spiel, dass starke Lastschwankungen hat bricht somit trotzdem bei der Framerate ein.

Ich glaub ich Spiel gleich unter Win 10 - das ist einfacher...

 

[fdsonne]

Jetzt würde mich nur noch brennend interessieren ob das eine Eigenart des Hexacores ist, sprich mit dem "X" Modell als Oktacore nicht auftritt!?
Jemand zufällig nen Oktacore im Zugriff um das Gegenzutesten?
Es war ja bis jetzt nicht nur einmal so, dass die "krummen" Core/CPU Anzahlen teilweise bei mancher Software komische Ergebnise ablieferten, obwohl es rein vom technischen her gar nicht sein dürfte...



Ansonsten würde ich hier aber klar trennen. Mir scheint es, als haben wir hier zwei grundverschiedene Probleme an der Mache.
- einerseits das nicht (voll) aufdrehen des Turbos, je nach Powersettings Mode vom Windows
- andererseits den Leistungsverlust, der einfach derart viel zu hoch ist, als das er nur von den paar popligen MHz mehr Turbo Clock kommen kann. Oben lese ich Werte von 8 bis 12 Minuten für den SPI 32M Lauf. Das ist viel zu viel für allein das Turbo Problem.

Für mich sieht das hier so aus, als ob der Windows Threadscheduler einfach ein "Problem" mit den Powermöglichkeiten der Haswell-E CPUs hat. Einerseits weil er schon horn alt ist und andererseits, weil er ggf. viel zu träge reagiert. Win10 in der Preview scheint das deutlich besser zu machen.
Aber auch das ist nicht verwunderlich, wo doch der Threadscheduler von MS immer den CPU Generationen stark hinterher hinkt. Erst Windows 7/2008 R2 konnte mit SMT von Intel brauchbar umgehen, bis einschließlich Vista hat der Scheduler das offenbar als eigenen Core interprätiert. Erst 8/8.1/2012/2012 R2 konnte brauchbar mit CMT bei den AMD BDs richtig umgehen. Bei 7 und älter hat das nicht sonderlich gut funktioniert usw.

Den Leistungsverlust in Singlethread Last schiebe ich aber eindeutig den Powersettings selbst zu, nicht der Hardware oder auch nicht dem Scheduler. Einfach weil die Settings scheinbar so konservativ agieren, um möglichst viel Strom zu sparen. Bestes Beispiel dafür ist doch aktuell auch die GM204 GPU von NVidia. Die im "normalen" Spielebetrieb durchaus für 28nm in Verbindung mit der Performance beeindruckt. Gibt man ihr aber richtig zu tun, dann säuft das Teil auch wie ein Loch... Weil die schnelle Umschaltung zwischen Lastzustand und keiner Last dann nicht mehr funktioniert und man somit auch den Verbrauch nicht mehr "künstlich" drücken kann. -> ein Ähnliches Verfahren scheint Intel auch hier mit Haswell-E anzuwenden. Zum einen, weil sich die Cores selbst schlafen legen und zum anderen, weil sie wohl eine Weile benötigen, bis sie wieder voll da sind (inkl. Turbo) -> das bremst die Anwendungen aus. Und von den Werten her, die ich hier lese, könnte das sogar hinkommen.
Hier kann ich mir ebenso vorstellen, das der Win10 Scheduler spritziger agiert. Weil er entweder die Last nur auf nicht schlafende Cores verteilt oder aber, die Cores vor dem Last anlegen schon aufweckt.


Unterm Strich?
Ich würde das Thema nicht unbedingt überbewerten... Das die Stromsparmodi seit Jahr und Tag schon mit Einschränkungen verbunden sind, ist keine Neuheit... Das es sich hier nun ziemlich krass auswirkt, zwar schon, aber sei es drum... Wir wissen doch alle, dass die Stromsparmodi nicht für die Höchstleistung stehen. Eventuell tut man sich als Anwender dann einfach besser, wenn man den Energiesparplan wärend der Lastphasen selbst auf Höchstleistung stellt. Und in den idle Phasen runter dreht. Ist zwar ein Klick mehr, aber dafür lüppt es dann und man hat die Vorteile von beiden Welten. Die Zeiten der Eierlegenden Wollmilchsau sind für mich spätestens seit der Einführung der Powerdrosslung auf GPU Seite vorbei. Und das gibts seit Fermi v2 respektive Cayman bei AMD.

 

[ceti]

Das erscheint mir auch das einfachste zu sein. Ich habe ein Gadget erstellt und nun ist es halt 1 klick mehr. Habe vorhin mal ein Test mit einem Videocodierer gemacht, der Unterschied ist sehr krass, ausbalanciert 2-3 Kerne auf 3,7 ghz Rest unberührt und Codierungsrestzeit ca. 30 min.- dann Energie auf Höchstleistung, alle Kerne volle power und Rest Zeit des Codierungsvorganges halbiert. Habe vorher einen i5 gehabt mit 4 Kerne und 4 Threads, nun 6 Kerne und 12 Threads, hatte mich immer gewundert das es nicht schneller geht, aber hatte mich da vorher auch nicht sonderlich drum gekümmert. Dann kann man nur hoffen auf ein Update, seitens Microsoft oder Treiber von Intel, oder sogar ein Update vom Bios? Was macht den der Intel ME Treiber genau? Ist der nicht für die „Energie / Power Verwaltung“ verantwortlich?

 

[eagle*23*]

wie hast das mit dem Gadget gemacht ?

 

[Gelöschtes Mitglied 172838]

Nein, fdsonne. Die Energiespareinstellung sind nicht das Problem. Es keine Dauerlösung auf "Höchstleistung" zu stellen. Selbst mein i5 4300U kann das besser - ohne Höchstleistung.

Eher scheint die Ursache beim Windows Scheduler zu liegen. Schaut euch mal den Test von Bulldozer auf anandtech an. Da wird das Problem beschrieben und es passt sehr gut zu meinem Problem.

 

[fdsonne]

Nein, fdsonne. Die Energiespareinstellung sind nicht das Problem. Es keine Dauerlösung auf "Höchstleistung" zu stellen. Selbst mein i5 4300U kann das besser - ohne Höchstleistung.

Eher scheint die Ursache beim Windows Scheduler zu liegen. Schaut euch mal den Test von Bulldozer auf anandtech an. Da wird das Problem beschrieben und es passt sehr gut zu meinem Problem.

Wäre es der Scheduler, würde Höchstleistung im Energieschema aber keine Besserung bringen
Der Scheduler selbst scheint also zu funktionieren. Und genau das zu machen, was er soll.
Das Energieschema selbst ist aber dahingehend das größere Problem, wenn es zu lahm agiert... Wie oben beschrieben, sieht das für mich so aus, als würde Windows zu lange brauchen um die Cores aus dem Schlafmodus zu holen, was eben dann massiven Leistungsverlust zur Folge hat. Das passt auch zu den Aussagen oben, von wegen CoH ist lahm, was eigentlich nicht sein kann... Ob da nun 3,0 oder 4,0GHz anliegen, sollte für die alte Kamelle eher wurscht sein, nur wenn die Cores noch schlafen, die Threads, die CPU Rechenzeit wollen, aber diese nicht bekommen, weil der Core gerade geweckt wird bzw. sich noch im idle Mode befindet, ists logisch, das es dann ruckelt...


PS: und nein, ich meine nicht als Dauerlösung Höchstleistung als Energieprofil zu verwenden, sondenr viel eher das dann zu verwenden, wenn man eben bildlich gesehen, Höchstleistung abrufen will... Und das wollt ihr doch? Oder sehe ich das falsch?
Ihr wollt maximale SingleThread Performance...
Für mich hat das hier gerade so bisschen den Touch, als will man hier das 1l Auto mit 300km/h über die Bahn bewegen, aber blos nicht den Verbrauch, der für diese Geschwindigkeit notwendig ist, zahlen
Oder anders ausgedrückt, willst du Strom sparen, läuft es wohl darauf hinaus, damit leben zu müssen, bis ein Windows sich auf die aktuellen Techniken angepasst hat. Oder du schenkst dir den Mehrverbrauch und hast die Performance sofort, hier und jetzt.

Was eventuell noch was bringen könnte, wäre C6 im Bios/UEFI zu deaktivieren. Klar, kostet auch Strom und treibt gerade den idle Verbrauch nach oben, würde das Leistungsproblem ggf. aber vollständig umgehen...

Der i5 4300U kann das im übrigen auch nicht wirklich besser, er scheint viel eher den massiven Vorteil zu haben, das Windows bei nur zwei Cores eben die anliegende Systemgrundlast über diese beiden Cores verteilt. Somit ist in SingleThread Volllastphasen der zweite Core damit beschäftig, die Grundlast abzufrühstücken -> schläft also nicht. Und somit ist im Fall des rumschubsens des Threads zwischen diesen beiden Cores keine Zeit verschwendet, da beide Cores voll da sind.

 

[nemihome]

Wie man ja an der Umsetzung in Windows 10 sieht, ist es aber nicht erforderlich alle Kerne hochzupowern, wenn Leistung auf einem benötigt wird. Windows 10 klebt den Mainthread einfach an einen Ern z.B. bei ESO - der wandert dort scheinbar nicht.

SuperPi wandert auch bei Windows 10 - aber ich vermute einfach langsamer.

So oder so muss man nicht aller Kerne auf Maximum fahren, um Singlethread Leistung zu bekommen, sofern das im Betriebssystem ordentlich gelöst ist.

C6 deaktivieren bringt übrigens nichts, hatte ich schon.

 

[fdsonne]

sofern das im Betriebssystem ordentlich gelöst ist.

Dann verwendet man halt einfach Windows 10 und gut ist
Ich mein, wir meckern hier auf sehr hohem Niveau... Win7 ist horn alt im Vergleich und die CPU Generation vergleichsweise neu.

 

[eagle*23*]

Na ist doch bei Win8 auch so und das ist nicht alt
Bis Win 10 rauskommt ist allerdings Hasi E wieder alt

 

[Bunghole Beavis]

Das Verhalten ist nichts Neues. Lässt sich auf Intel oder AMD System beobachten. Der Windows 7 Scheduler bzw. die Energieschema, dass die Powerstates verwaltet, läuft nicht optimal bzw zu langsam. Durch manuelles zuweisen der Threads, Prozesse und Prioritäten lässt sich die Performance um x% steigern. Bei Windows 8.1 ist es einwenig besser gelöst.

Dem gewöhnlichen Nutzer fällt dies in der Regel nicht auf. Hardwarezeitungen testen auf optimierten Plattformen und benchen mit schnellstmöglichen Setup.

@fdsonne
CoH1 ist extrem CPU-limitiert auf 1,0-1,5 Kerne. Dort macht es einen beträchlichten Unterschied, ob nun 3 oder 4 GHz anliegen. Hüpft der Takt ständig dann zwischen Idle und Load hin und her wirds richtig nervig.

 

[Santa]

...
Ich konnte mit dem Sandy-E bei einem kurzen Test aller Windows Client Versionen ab 7 mit einem einzelnen Prime Worker keine Unterschiede im Turbo-Verhalten fest stellen. Egal ob fest gepinnt oder nicht, die CPU lief nie mehr als 4,2 GHz singlethreaded.
Jeweils mit dem Energiesparprofil "Ausbalanciert" getestet.

Dann kann also selbst Windows 10 noch keine übertaktete Hexa-Core-CPU bei „single-threaded“ Programmen voll ausfahren, ohne am Energiesparplan rumzufummeln??? Da hatte ich mir ein bisschen mehr erhofft...

 

[nemihome]

Voll ist eh relativ. Mit dem Haswell-E zündet er den Turbo auf die Maximalfrequenz aber trotzdem verliert man noch Zeit durch das ständige geswitche und hochtakten.

 

[fdsonne]

@fdsonne
CoH1 ist extrem CPU-limitiert auf 1,0-1,5 Kerne. Dort macht es einen beträchlichten Unterschied, ob nun 3 oder 4 GHz anliegen. Hüpft der Takt ständig dann zwischen Idle und Load hin und her wirds richtig nervig.

Das ist mir schon klar, nur kommen die Werte definitiv nicht von den popligen 10-20% mehr Takt. Man spricht von teils deutlichen FPS Einbrüchen, was faktisch nicht allein auf das bisschen Taktunterschied zurückzuführen sein kann...
Zwischen idle 1,2GHz und vollem Takt ggf. gar mit OC, sieht das dann schon etwas anders aus...
Nur würde ich das nicht überbewerten.

Na ist doch bei Win8 auch so und das ist nicht alt

Soweit ich das sehe ist der Kernel aber älter als die CPUs von daher...

 

[ceti]

wie hast das mit dem Gadget gemacht ?

Das Gedget heißt "PowerStatus11.gadget", damit hat man dann ganz normal das gadget aufn desktop und kann mit einem Mausklick zwischen den 3 Energieoptionen hin und her klicken. Windows 7 hat ja eh die gadgets, einfach mit rein installieren, ich habe es über das Gadgets- tool für Windows 8.1 "DesktopGadgetsRevived-2.0" installiert.
Erscheint im Moment die einfachste Lösung zu sein, wirklich dann nur ein klick

 

[Phantomias88]

Danke, hilft bei mir zumindest nicht. Vielleicht bei Sandy. Ich hab sowohl das Regsetting als auch das Tool getestet.

Schade, bei mir klappt es bisher tadellos.
Wobei ich es nur im Profil Höchstleistung deaktiviert habe, welches eher weniger genutzt wird.
Die meiste Zeit ist das Profil Ausbalanciert aktiv.
Process Lasso ist auch hilfreich, gerade wenn Prozesse eingeschränkt sind. (gelbe Balken im Diagramm)
Die treten bei mir aber nur bei exzessivem Multi-threading (96+) auf.

Das ist mir schon klar, nur kommen die Werte definitiv nicht von den popligen 10-20% mehr Takt. Man spricht von teils deutlichen FPS Einbrüchen, was faktisch nicht allein auf das bisschen Taktunterschied zurückzuführen sein kann...
Zwischen idle 1,2GHz und vollem Takt ggf. gar mit OC, sieht das dann schon etwas anders aus...
Nur würde ich das nicht überbewerten.

Soweit ich das sehe ist der Kernel aber älter als die CPUs von daher...

Naja Win8 wurde ja auch für "Mobile" ausgelegt, dort wird schon lange "power gating" vom feinsten betrieben.
AMD wirbt ja bei den FX CPUs mit dem einschalten innerhalb eines Takt Zyklus.
Was bei Intel noch hinzu kommt ist der PCI Express Controller in der CPU, dafür gibt es auch eine Option bei den erweiterten Energieoptionen.

 

[eagle*23*]

Das Gedget heißt "PowerStatus11.gadget", damit hat man dann ganz normal das gadget aufn desktop und kann mit einem Mausklick zwischen den 3 Energieoptionen hin und her klicken. Windows 7 hat ja eh die gadgets, einfach mit rein installieren, ich habe es über das Gadgets- tool für Windows 8.1 "DesktopGadgetsRevived-2.0" installiert.
Erscheint im Moment die einfachste Lösung zu sein, wirklich dann nur ein klick

ah ok danke

 

[H_M_Murdock]

Hab das ganze mal auf meinem Xeon E5-1650 V2 getestet (non-OC).
Prime auf einem Kern fest genagelt.
"Ausbalanciert": 3,5 GHz
"Höchstleistung mit CPU auf min. 5%": 3,6 GHz mit SPrüngen auf 3,7 GHz.

Bei dieser CPU können die Kerne scheinbar übrigens auch gleichzeitig unterschiedliche Multis fahren.

 

[nemihome]

Als Zwischeninfo - sowohl die c't als auch ASRock haben mal bei Intel nachgefragt. Evtl. lässt sich ja beim Haswell-E über Treiber Besserung erzielen. Sonst muss wohl Microsoft ran.

 

[eagle*23*]

oh ok danke für die Mühe

 

[H_M_Murdock]

Super vielen Dank!

EDIT:
Ich habe heute in der c't 23/2014 mit Freude den Leserbrief von Torsten Wirth über das Turbo-Problem gelesen und direkt noch einen hinterher geschickt da das Problem ja nicht ausschließlich beim Haswell-E auftritt und zumindest beim Sandy-E auch unter Windows 8.1 und der Windows 10 Preview nicht aus der Welt ist.

Ich bin gespannt ob die c't dem weiter nach geht.

 

[Gelöschtes Mitglied 172838]

Irgendwas neues zu dem Thema?

 

[nemihome]

Nicht wirklich. Von Intel gibt es weder über ASRock noch über die c't eine Reaktion. Sieht mir so aus, als wenn das ausgesessen wird. Es betrifft ja nur einen Teil der Anwender, von denen merken es nicht alle und von denen die es merken wendet sich kaum einer an den Support. Ist also nichts was man nicht aussitzen könnte...

 

[H_M_Murdock]

Ich hatte das Thema zwar auch noch mal als Leserbrief an die c't geschickt aber auch nichts weiter hilfreiches zurück bekommen außer dass sie das selber noch am klären sind.