Hallo Community!
Derweil plagt mich ein Problem um den Intel Core i7-6700K auf dem ASRock Z170 Extreme6+.
Mir ist aufgefallen, dass die Vcore sich verändert hat: Die ursprünglichen Werte sind gewesen 0.800 ~ 1.296 V und die gegenwärtigen Werte betragen 0.770 ~ 1.390 V.
Ich kenne das Symptom, die Erhöhung von der Vcore, normalerweise insoweit, dass das Voltage Regulator Module nicht mitzieht.
Auch schon durch eine gefährliche Netztrückwirkung von einem elektrischen Wandbild, die Vcore stieg nach diesem Übertritt von der Spitzensperrspannung fast überdimensional gen 1.4 V bei einem AMD Athlon II X2 250 und sistierte unveränderlich auf dem erzielten Wert. xD
Einleitung: Da die Intel-Prozessoren per Core-based and Package-based State schalten können das Taktsignal und die Kernspannungen, so ziemlich alles, aus dem Prozessor heraus generiert werden. Was heißt "können"? So ist es!
Das Redstone 2 für Windows 10 hat die Intel Speed Shift Technology zugänglich gemacht, eine Methodik über das Advanced Configuration and Power Interface, welches den Core-based and Package-based State via Windows regulieren kann, fernab der Firmware (UEFI/SMBIOS).
Natürlich bediene ich mich derer Methode über die <Energieoptionen> ->> <Prozessorenergieverwaltung> ->> <Maximale Prozessorfrequenz>, um den Intel Core i7-6700K zu limitieren, aktuell auf Core State #30 @ 1.085 V (>1.090 V) bei unverändertem BCLK.
Ich hatte nach dem Upgrade auf Redstone 2 kein Glück gehabt, denn die Energieverwaltung ist grottig gewesen. Das Voltage Regulator Module nervte ununterbrochen durch Coil Whining und vielen Schaltvorgängen, sobald nur eine etwas kleinere Last anstand, es störte während der Videowiedergabe. Infolgedessen von nachträglichen Windows-Patchdays legte sich dieses Symptom, mittlerweile ist es gänzlich vorbei. Das Problem konnte ich somit gezielt auf die Treiber des Kernel-Mode Driver Framework eingrenzen, womöglich spielten auch die Treiber des User-Mode Driver Framework in die Karten.
Was seither noch nicht *gänzlich* behoben wurde ist ein Problem per USB: Ein jedes Gerät, was daran angeschlossen ist, lässt sich nicht über die Windows interne Funktion "Hardware sicher entfernen" abdocken.
Zuvor bestand noch das Problem, dass per Hot Swapping an SATA eingebundene Datenträger sich nach erzwungenem Spindown abrupt zum Spinup übergegangen sind. Das Kernproblem besteht jedoch weiterhin, jenes ich zu USB beschrieben habe, dass per SATA - Hot Swapping eingebundene Datenträger sich über "Hardware sicher entfernen" nicht abdocken lassen - sie tauchen dort noch nicht einmal mehr auf. Es muss demnach jedesmal ein externes Tool wie HDDScan herhalten.
Dieses Problem um USB und SATA beobachte ich seit Redstone 2 generell an verschiedenen Plattformen, ungleich ob auf dem ASRock Fatal1ty X370 Professional Gaming oder auf dem ASUS Prime X299-A, und andere berichten darüber. Es ist somit keine Komplikation von einer bestimmten Plattform und auch keine, von welcher eine AMD-Plattform verschont ist.
Was mich aktuell stört, es besteht erst seit wenigen Wochen, dass die Performance des Intel Core i7-6700K gesungen ist; er mehrt an so Sachen wie dem Aufrufen des Google Chrome ungewöhnlich lange; - Webseiten in aufwändiger Aufmachung verzögern am Aufbau um bis zu wenigen Selunden, mitunter verläuft das Scrollen auf diesen Webseiten stockend ab. Nach meiner Beobachtung entspricht dieses Verhalten dem Halt State.
Bisher ist mein Verdacht auf das Thermal Interface Material gefallen; - sowohl das TIM unterm Heatspreader als ebenso das darüber.
Ich hatte bis vor einigen Stunden noch die inoffizielle Version 10.1.1.44 der Intel Chipset Device Software installiert gehabt, auf welche ich vor wenigen Wochen aktualisiert hatte. Aktuell bin ich auf die offizielle Version 10.1.1.42 zurückgegangen.
Ich kann seither berichten, dass sich dieses Symptom um den Google Chrome gebessert hat, jedoch verläuft das Aufrufen weiterhin zu zögerlich ab.
Das Intel Management Engine Interface ist nach wie vor auf Version 11.7.0.1037.
Die Auslagerungsdatei ist seit eh und je inaktiv, sodass der Google Chrome nach einem erfolgten Aufruf in mindestens von der Swapfile des Hauptspeichers lade, wenngleich er über die Speicherpools auf der Samsung SSD 850 EVO MZ-75E500B puffere.
Um das Problem weiter eingrenzen zu können: Ich habe mit dem Corsair Vengeance LED CMU16GX4M2C3200C16R [v4.24] ein wenig experimentiert, vor etlichen Wochen mit 3466 MHz @ 16-18-18-36-2N-1.35V, was sich an einem darauffolgenden Tag im Battlefield 3 Multiplayer als instabil erwiesen hat, demzufolge bin ich auf Stock zurück 3200 MHz @ 16-18-18-36-2N-1.35V. Bis vor wenigen Tagen probierte ich es nochmals, um zu sehen, ob die 3600 MHz ohne angehobener VDDR auf verschieden hohen Timings anvisierbar sind, aber damit startet der Rechner nicht einmal über die Mainboard-Firmware hinaus. Das Optimum scheinen die 3466 MHz @ 18-19-19-39-2N-1.35V zu sein, dennoch bin ich auf die Stock-Values zurück, weil der Leistungssprung nach meiner Erachtung keiner ist.
Ich habe nun also einen weiteren Sündenbock, der die Ursache für die hohe CPU-Latenz sein kann, der Arbeitsspeicher.
Wenn die Vcore, auf welche ich anfangs eingegangen bin, die Wirkung dessen ist, dann muss es mit der Steuerspannung zum Arbeitsspeicher zusammenhängen.
Ich bin bisher noch keinen CMOS(-SRAM)-Reset angegangen, bisher genügte der herkömmliche BIOS-Reset und das Laden der gespeicherten Konfigurationen aus, aber wenn es sich wirklich bloß um einen Konfigurationsfehler seitens der Mainboard-Firmware handelt, bedingt durch den Arbeitsspeicher, dann habe ich noch Hoffnung, dass das Mainboard die einstigen Microcode-Values korrekt ausliest und anwendet.
Die Spannung da oben ist viel zu hoch und die Performance noch nicht dort angelangt, wo sie gewesen ist und wieder sein soll!
Ich bedanke mich für euer Interesse an diesem Roman!
LG!
Derweil plagt mich ein Problem um den Intel Core i7-6700K auf dem ASRock Z170 Extreme6+.
Mir ist aufgefallen, dass die Vcore sich verändert hat: Die ursprünglichen Werte sind gewesen 0.800 ~ 1.296 V und die gegenwärtigen Werte betragen 0.770 ~ 1.390 V.
Ich kenne das Symptom, die Erhöhung von der Vcore, normalerweise insoweit, dass das Voltage Regulator Module nicht mitzieht.
Auch schon durch eine gefährliche Netztrückwirkung von einem elektrischen Wandbild, die Vcore stieg nach diesem Übertritt von der Spitzensperrspannung fast überdimensional gen 1.4 V bei einem AMD Athlon II X2 250 und sistierte unveränderlich auf dem erzielten Wert. xD
Einleitung: Da die Intel-Prozessoren per Core-based and Package-based State schalten können das Taktsignal und die Kernspannungen, so ziemlich alles, aus dem Prozessor heraus generiert werden. Was heißt "können"? So ist es!
Das Redstone 2 für Windows 10 hat die Intel Speed Shift Technology zugänglich gemacht, eine Methodik über das Advanced Configuration and Power Interface, welches den Core-based and Package-based State via Windows regulieren kann, fernab der Firmware (UEFI/SMBIOS).
Natürlich bediene ich mich derer Methode über die <Energieoptionen> ->> <Prozessorenergieverwaltung> ->> <Maximale Prozessorfrequenz>, um den Intel Core i7-6700K zu limitieren, aktuell auf Core State #30 @ 1.085 V (>1.090 V) bei unverändertem BCLK.
Ich hatte nach dem Upgrade auf Redstone 2 kein Glück gehabt, denn die Energieverwaltung ist grottig gewesen. Das Voltage Regulator Module nervte ununterbrochen durch Coil Whining und vielen Schaltvorgängen, sobald nur eine etwas kleinere Last anstand, es störte während der Videowiedergabe. Infolgedessen von nachträglichen Windows-Patchdays legte sich dieses Symptom, mittlerweile ist es gänzlich vorbei. Das Problem konnte ich somit gezielt auf die Treiber des Kernel-Mode Driver Framework eingrenzen, womöglich spielten auch die Treiber des User-Mode Driver Framework in die Karten.
Was seither noch nicht *gänzlich* behoben wurde ist ein Problem per USB: Ein jedes Gerät, was daran angeschlossen ist, lässt sich nicht über die Windows interne Funktion "Hardware sicher entfernen" abdocken.
Zuvor bestand noch das Problem, dass per Hot Swapping an SATA eingebundene Datenträger sich nach erzwungenem Spindown abrupt zum Spinup übergegangen sind. Das Kernproblem besteht jedoch weiterhin, jenes ich zu USB beschrieben habe, dass per SATA - Hot Swapping eingebundene Datenträger sich über "Hardware sicher entfernen" nicht abdocken lassen - sie tauchen dort noch nicht einmal mehr auf. Es muss demnach jedesmal ein externes Tool wie HDDScan herhalten.
Dieses Problem um USB und SATA beobachte ich seit Redstone 2 generell an verschiedenen Plattformen, ungleich ob auf dem ASRock Fatal1ty X370 Professional Gaming oder auf dem ASUS Prime X299-A, und andere berichten darüber. Es ist somit keine Komplikation von einer bestimmten Plattform und auch keine, von welcher eine AMD-Plattform verschont ist.
Was mich aktuell stört, es besteht erst seit wenigen Wochen, dass die Performance des Intel Core i7-6700K gesungen ist; er mehrt an so Sachen wie dem Aufrufen des Google Chrome ungewöhnlich lange; - Webseiten in aufwändiger Aufmachung verzögern am Aufbau um bis zu wenigen Selunden, mitunter verläuft das Scrollen auf diesen Webseiten stockend ab. Nach meiner Beobachtung entspricht dieses Verhalten dem Halt State.
Bisher ist mein Verdacht auf das Thermal Interface Material gefallen; - sowohl das TIM unterm Heatspreader als ebenso das darüber.
Ich hatte bis vor einigen Stunden noch die inoffizielle Version 10.1.1.44 der Intel Chipset Device Software installiert gehabt, auf welche ich vor wenigen Wochen aktualisiert hatte. Aktuell bin ich auf die offizielle Version 10.1.1.42 zurückgegangen.
Ich kann seither berichten, dass sich dieses Symptom um den Google Chrome gebessert hat, jedoch verläuft das Aufrufen weiterhin zu zögerlich ab.
Das Intel Management Engine Interface ist nach wie vor auf Version 11.7.0.1037.
Die Auslagerungsdatei ist seit eh und je inaktiv, sodass der Google Chrome nach einem erfolgten Aufruf in mindestens von der Swapfile des Hauptspeichers lade, wenngleich er über die Speicherpools auf der Samsung SSD 850 EVO MZ-75E500B puffere.
Um das Problem weiter eingrenzen zu können: Ich habe mit dem Corsair Vengeance LED CMU16GX4M2C3200C16R [v4.24] ein wenig experimentiert, vor etlichen Wochen mit 3466 MHz @ 16-18-18-36-2N-1.35V, was sich an einem darauffolgenden Tag im Battlefield 3 Multiplayer als instabil erwiesen hat, demzufolge bin ich auf Stock zurück 3200 MHz @ 16-18-18-36-2N-1.35V. Bis vor wenigen Tagen probierte ich es nochmals, um zu sehen, ob die 3600 MHz ohne angehobener VDDR auf verschieden hohen Timings anvisierbar sind, aber damit startet der Rechner nicht einmal über die Mainboard-Firmware hinaus. Das Optimum scheinen die 3466 MHz @ 18-19-19-39-2N-1.35V zu sein, dennoch bin ich auf die Stock-Values zurück, weil der Leistungssprung nach meiner Erachtung keiner ist.
Ich habe nun also einen weiteren Sündenbock, der die Ursache für die hohe CPU-Latenz sein kann, der Arbeitsspeicher.
Wenn die Vcore, auf welche ich anfangs eingegangen bin, die Wirkung dessen ist, dann muss es mit der Steuerspannung zum Arbeitsspeicher zusammenhängen.
Ich bin bisher noch keinen CMOS(-SRAM)-Reset angegangen, bisher genügte der herkömmliche BIOS-Reset und das Laden der gespeicherten Konfigurationen aus, aber wenn es sich wirklich bloß um einen Konfigurationsfehler seitens der Mainboard-Firmware handelt, bedingt durch den Arbeitsspeicher, dann habe ich noch Hoffnung, dass das Mainboard die einstigen Microcode-Values korrekt ausliest und anwendet.
Die Spannung da oben ist viel zu hoch und die Performance noch nicht dort angelangt, wo sie gewesen ist und wieder sein soll!
Ich bedanke mich für euer Interesse an diesem Roman!
LG!
Zuletzt bearbeitet:
Ob es daran liegt, ich weiß es echt nicht.
