i7 5820k OC

Ich hab mal ne Frage zu den C-States, die soll man ja bei OC deaktivieren, weil die die Stabilität beeinflussen, aber warum eigentlich? Bzw ich seh das Problem nicht, die Senken doch nur den Takt?

Das Problem dabei ist etwas komplexer.

Die C-States greifen sehr viel schneller ein, als einem das CPU-Z glauben machen will, eine solche CPU kann mit jedem Kern innerhalb von Millisekunden die States wechseln. Das nur im Voraus erwähnt damit das folgende klarer wird.

Jedes mal, wenn du die last und erst recht die Spannung änderst gibts ein gewisses Nachschwingen weil Spannungswandler viel träger sind als die CPU selbst. Sprich wenn die Last oder Spannung von hoch nach tief soll hast du ein Überschwingen, wenns anders rum ist ein unterschwingen.
Wenn du die C-States deaktivierst läuft deine CPU beispielsweise immer bei 1,2v. Wenn jetzt aus dem nichts große last angelegt wird taktet die CPU extrem schnell hoch und fordert Leistung. Die SpaWas sind träger und schieben die Leistung nach, die ersten paar Takte muss die CPU also mit etwas geringerer Spannung leben weil das Board nicht schnell genug nachliefern kann und den Energiehunger stiollen kann.

Der Effekt wird jetzt noch viel größer, wenn die Spannung nicht sowieso schon recht weit oben war sondern noch bei 0,7v rumdümpelt. Hier schaltet die CPU genauso schnell hoch, das Board muss aber nicht nur den Spannungsabfall von 1,2 auf 1,1v oder so abfangen sondern muss zusätzlich noch generell die Spannung von 0,7 auf 1,2 hgochdrücken. Das dauert länger und ist aufwendiger zu machen. In der Zeit wo das länger dauert ist aber eine CPU die am Limit getaktet ist schon abgestürzt wo die, die bei 1,2 gehalten wird noch weitermachen kann. Deswegen ist eine dynamische Spannungsgebung immer weniger effektiv bei OC wie eine konstante Spannung.
 
Dann dürfte es aber doch bei gefixter Spannung keine Probleme damit geben, oder?

Doch, nur sind die nicht so gravierend da die Schwingungen dann kleiner sind.

Wie du sicher weißt ist Leistung = Stromstärke mal Spannung. Wenn ein übertakteter Haswell-E von 0 auf 100 fährt (wenn du Prime startest) steigt die Verlustleistung sagen wir mal von 5W auf 200W an. Es ist natürlich (mit verwendeter Technik) unmöglich, das innerhalb einer Mikrosekunde zu bewerkstelligen, so extrem schnell solche Leistungen rauszuhauen geht nunmal nicht, die SpaWas brauchen da nen kurzen Moment.
Die CPU kann aber sehr wohl so schnell schalten und will die Leistung nunmal haben. Resultat ist, dass die Spannung im Moment des Umschaltens abfällt, genau wie es die Spannung einer Batterie tut wenn du ne Lampe anklemmst oder wie die Drehzahl eines schwächeren Motors kurz etwas sinkt wenn man die Klimaanlage schnell auf die höchste Stufe stellt.

Dieses kurze Absinken ist immer da, nur ist die Zeit bis wieder 1,2v anliegen kürzer, wenn der Ausgangspunkt beim Umschalten auf Last eben schon bei 1,2v war und nicht bei 0,7.

Übrigens hat die Agressivität, mit der die Spannungswandler versuchen sowas auszugleichen den Namen "Loadline Calibration", das kennste wahrscheinlich. Wenn mans ZU agressiv hat ist der zeitraum bis die 1,2v wieder anliegen vielleicht kürzer und die CPU kann etwas mehr Takt stabil halten beim Umschalten, durch den agressiven Vorgang schießen die SpaWas aber drüber, sprich mit gewalt auf 1,2v springen hat zur Folge dass man überschwingt ("overshoot") und die CPU kurz mal 1,3 oder 1,4v abbekommt was nicht so arg gesund ist. Gleiches nochmal wenn die last dann wieder weg ist und die SpaWas noch am drücken sind wo die CPU schon wieder schläft, da können ebenfalls solche Spitzen auftreten.

So sehen Spannungsverläufe in der Realität aus wenn man beispielsweise auf 1,25v fixiert:
http://images.anandtech.com/reviews/cpu/intel/penryn-oc2/transient_no_vdroop_no_offset.jpg
 
Die LLC beeinflusst bei Haswell-E durch den in die CPU integrierten Wandler doch nur die Input-Voltage und nicht den Vcore, oder habe ich da etwas falsch verstanden?

Und der Spannungsabfall im Belastungsfall ist ja auch großteils erwünscht, da durch die höhere Temperatur im Lastfall der Innenwiderstand im Chip abfällt und dadurch sonst sehr hohe Ströme durch die CPU schießen würden.
 
Zuletzt bearbeitet:
Ja die LLC kann man bei Haswell E aber nur für die Input Spannung einstellen, soweit ich weiß. Nur verstehe ich den Zusammenhang von Takt und Verlustleistung nicht so ganz. Der Unterschied zwischen 4.4GHz @ Idle und 1.2GHz @ Idle dürfte wahrscheinlich im Einstelligen Wattbereich liegen. Und für mein Verständnis Treten die Schwingungen nicht auf weil der Takt sich ändert sondern weil der Prozessor plötzlich stark beansprucht wird.

Dementsprechend dürfte es doch keinen (großen) Unterschied machen ob die C-States an oder aus sind, solange die Spannung fixiert wird. Vielleicht reime ich mir aber auch gerade totalen Mist zusammen :ugly:
 
Theoretisch ja. Bei einem so komplexen Gerät wie einer modernen CPU würde ich aber nicht über die Brücke gehen wollen zu sagen dass die LLC keinen Einfluss mehr auf die vCore hat... :D

Der Zusammenhang von Takt und Verlustleistung ist simpel: Er ist (annähernd) linear. ABER: Das gilt nur für ARBEITStakte - wenn deine CPU bei 4 GHz nichts tut sind 99,999% aller Takte ja Leerzyklen die keine verlustleistung abgeben (deswegen ist der Unterschied so gering).
 
Der Zusammenhang von Takt und Verlustleistung ist simpel: Er ist (annähernd) linear. ABER: Das gilt nur für ARBEITStakte - wenn deine CPU bei 4 GHz nichts tut sind 99,999% aller Takte ja Leerzyklen die keine verlustleistung abgeben (deswegen ist der Unterschied so gering).
Das ist mir schon bewusst, aber darauf wollte ich nicht hinaus. Ich meinte, dass der Taktwechsel bzw. das Hochtakten wenn Last angelegt wird eigentlich keine Auswirkungen auf die Verlustleistung hat.
Deswegen sollte theoretisch die Schwingung die gleiche sein, egal ob die CPU erst hochtaktet oder schon 4.4GHz anliegen, solange die Spannung gleich bleibt.
 
Nicht genau die gleiche (Taktdomänen zu verändern erfordert CPU-intern Anpassungen und Syncronisationen die extrem schnell ablaufen) aber sehr ähnlich, das stimmt.
Hier sollte der OC-Stabilitätsunterschied sehr gering sein, wenn auch nicht ganz Null.
 
hi schaut euch mal bitte die Bilder an
hat jemand eine Idee wie sowas zustande kommt cpu ist niemal runtergefallen oder sowas Rechner läuft auch nicht mehr er bootet nur bis zu einem gewissen punkt qcode 94-95 und vga led bleibt an ich habe mittlerweile 3 unterschiedliche gpus getestet immer das gleiche
Mainboard ist auch ok habe gedacht der Fehler liegt da aber Alternate hat es getestet und mir wieder zurück geschickt als funktionstüchtig
als ich die kiste wieder zusammen gebaut habe ist mir zufällig aufgefallen das mein i7 5820k an einer Kontaktfläche komplett blank ist also nicht mehr gold und ein zweiter Kontakt ist auch zum teil blank es schaut sogar so aus als wen der blanke Kontakt etwas tiefer liegt als die anderen ist auf den Bildern schwer zu erkennen

weis jemand wie sowas passieren kann ?
ich werde die CPU morgen nach Alternate schicken und hoffen das der Prozessor umgetauscht wird
 

Anhänge

  • DSC_1651.JPG
    DSC_1651.JPG
    1,8 MB · Aufrufe: 156
  • DSC_1653.JPG
    DSC_1653.JPG
    1,7 MB · Aufrufe: 147
  • DSC_1652.JPG
    DSC_1652.JPG
    1,8 MB · Aufrufe: 104
ok das ist interessant ich werde am Board mal die kontakte überprüfen ob mir da was auffälliges ins Auge fällt das ding lief seit dem kauf tadellos ohne Problem und mitten beim benchen freez und seit dem ist das

was mich halt am Anfang gewundert hat das der qcode und die vga led auf die gpu hinweisen
aber die gpu funktioniert auch in einem anderen Rechner getestet rein theoretisch hätte ja die cpu led leuchten müssen
 
Zuletzt bearbeitet von einem Moderator:
Du glaubst tatsächlich, dass diese LEDs so komplex verschaltet sind, dass sie bei tausenden von Pins und Leitungen immer 100% korrekt das fehlerhafte Teil beziffern können?
Sorry aber die LEDs sind mehr Marketing als Technik. Mehr als "wenn eine brennt stimmt was nicht" können die streng genommen nicht. Wenn man Glück hat zeigen sie einem immerhin die grobe Richtung. ;)
 
sorry ja ich muss zugeben das ich schon in dem glauben wahr das die LEDs zeigen was Sache ist
ich hoffe Alternate nimmt sich zwecks Garantie was von der cpu an
und danke für die hinweise
 
Normalerweise sollte sowas ein Gewährleistungsfall sein da du als Nutzer nichts dafür konntest, sprich Intel wird die CPU sehr wahrscheinlich ersetzen. Das kann aber ne ganze weile dauern bis das abgewickelt ist.
 
@hellr3aser

Wie sieht dein Sockel, der zutreffende Pin aus, falls überhaupt etwas zu erkennen sein sollte.
Geht übrigens nur mit einer Lupe, weiß ich nur von einem Arbeitskollegen der 3 verbogen Pins hatte und ich durfte den Kamikaze mit einer Spitzpinzette richten. Glück gehabt, aber das klappt nicht immer ohne Alkohol ;)
Gruss

@KempA
Im Idle 0.9 Volt, bist du sicher da bei mir 0.725
auf allen Sensoren, egal welches Programm, angezeigt wird. Ich habe Adaptive- Mode bei 1.100 Volt und VCore Adaptive Voltage mit
- 0.055 Volt. ( Board Asrock), CPU3700/CACHE3500/RAM2667 MHz
 
Zuletzt bearbeitet:
Nicht genau die gleiche (Taktdomänen zu verändern erfordert CPU-intern Anpassungen und Syncronisationen die extrem schnell ablaufen) aber sehr ähnlich, das stimmt.
Hier sollte der OC-Stabilitätsunterschied sehr gering sein, wenn auch nicht ganz Null.

Ich glaube dass der Unterschied schon messbar ist. Ich habe meine zB CPU auf adaptive -0.001v eingestellt mit der Vcore 1,085v für 4.0GHz. Wenn alle C-States aktiv sind, und die Windows Energie-Einstellungen auf ausbalanciert stehen, taktet er auf 1.2 GHz runter im Idle mit entsprechend niedriger Voltage. Wenn ich Cinebench laufen lasse ist der MultiCore Test nun reproduzierbar niedriger als wenn ich einfach die Windows Energieeinstellungen auf Höchstleistung stelle, womit er den Takt 4.0 GHz auch im Idle beibehält. (Schaltet Windows dabei einfach die C-States ab bzw spricht sie nicht an?).
Im Singlecore-Test ist das Ergebnis zwischen beiden Prozeduren sehr unterschiedlich, was ich aber vor allem auf die Vergleichsweise niedrige Beanspruchung der gesamten CPU ( 100% / 6 Kerne ) zurückführe, und die Belastung durch die Kerne wechselt. Auch da wirken sich dann ja diese Schaltzeiten aus, oder?

Also betreibt ihr Eure CPU immer gefixter Spannung und abgeschalteten C-States?
 
Dass der Cinebench etwas höher ausfällt ohne C-States liegt daran, dass der Zeitraum den die CPU zum hochtakten braucht in dem Falle wegfällt und die maximale performance ein paar Millisekunden früher da ist. Das ist aber nur benchmark und nicht praxisrelevant (entsprechend hab ich die C-States natürlich an). Wenn du noch 3 Punkte mehr haben willst kannste die Prozesspriorität des Cinebench im Taskmanager noch auf hoch stellen. :ka:

Wenn Windows auf "Höchstleistung" steht wird einfach kein C-State verwendet. Das ist genau als wenn du sie im UEFI abschaltest.

Dass der Singlecore-Test schlechter abschneidet hat den gleichen grund wie oben beschrieben, nur weil der Scheduler den einen Thread öfter mal auf verschiedene Kerne schiebt haste den Effekt halt viele male hintereinander statt nur ein mal.
 
Bei mir hat es auch Praxisrelevanz. Ich berechne Abschnitte aus Datenbanken anhand vorgefertigter Definitionen (Multicore), alle x abgeschlossene Berechnungen schreibt er die Daten nieder was nur geringer Rechenaufwand ist und durch die SSD limitiert wird. Neue Daten werden leider nur von einem Singlecore-Prozess in die Database eingelesen. Hierbei habe ich im einen Unterschied von 15-20%. In der relativ viel längeren Multicore-Berechnung der fertig eingelesenen Abschnitte habe ich knapp 10% Unterschied.

Intel XTU benennt dieTDP im Idle in der Einstellung Höchstleistung mit 25-29 W, in der Einstellung Ausbalanciert mit 14-16 W. Wenn das Gesamtsystem laut diverser Tests 80 W im Idle verbrät ist das natürlich relativ wenig Unterschied. Oder gibt es auch C-States die den Rest der gesamten Plattform betreffen? Die geringen Werte der SSDs sind ja zu vernachlässigen.
 
Der Unterschied ist tatsächlich nicht so groß. Wenn du tatsächlich spürbare Vorteile in deiner speziellen Anwendung hast gibts keinen Grund, die "Höchstleistung"-Einstellung nicht auch zu nutzen (dafür ist die ja da).
 
Zurück