Raffnek30000
Freizeitschrauber(in)
es geht doch darum die leistung zu messen, wo ist das problem? und es sollte logisch sein das die power ohne OC gemessen wird. insofern muss man jetzt natürlich die specs die von intel empfohlen werden benutzen.
Special Instabile CPUs: So testet PCGH ab jetzt alle Core-Prozessoren der 13. und 14. Generation
- Ersteller PCGH_Dave
- Erstellt am
HardWareFresser87
Software-Overclocker(in)
Er möchte der nächste kollegah werden.Die Baseline, höhö. In letzter Zeit hast du es aber echt mit deinen Wortspielen
Tolotos66
Volt-Modder(in)
Ich habe das verstanden.
Es geht auch gar nicht um OC/UV!
Wenn/falls Intel einen passenden Code veröffentlicht, wären alle vorangegangagenen Meßreihen obsolet, da das Redakteurenteam quasi gezwungen wird, neue Reihen zu erstellen. Jeder will ja wissen, wo die Reise hingeht.
Deshalb auch meine Frage, ob man sich das jetzige "Gemesse" nicht lieber spart, da in absehbarer Zeit eh alles neu eruiert werden muß.
Möööglicherweise denke ich entweder zu gradlinig oder zu kompliziert
Gruß T.
lucky1levin
BIOS-Overclocker(in)
Das wird die neue ZukunftZuerst fackeln Grafikkarten ab, jetzt „rosten“ Prozessoren… Was kommt als nächstes? Oled Displays welche bei „normaler“ Nutzung nicht nur einbrennen sondern gleich in Flammen aufgehen?
Raffnek30000
Freizeitschrauber(in)
naja ist doof gelaufen, aber es wird ja immer der aktuelle stand gemessen. also jetzt mit den intel specs, wenn sich dann was durch updates ändert muss es noch mal gemacht werden. kein plan wie geil das die redaktion findet, aber das ist der job.Ich habe das verstanden.
Es geht auch gar nicht um OC/UV!
Wenn/falls Intel einen passenden Code veröffentlicht, wären alle vorangegangagenen Meßreihen obsolet, da das Redakteurenteam quasi gezwungen wird, neue Reihen zu erstellen. Jeder will ja wissen, wo die Reise hingeht.
Deshalb auch meine Frage, ob man sich das jetzige "Gemesse" nicht lieber spart, da in absehbarer Zeit eh alles neu eruiert werden muß.
Möööglicherweise denke ich entweder zu gradlinig oder zu kompliziert
Gruß T.
//EDIT
oder um es mit star wars zu sagen "das ist der weg"
XD
deadletters
Schraubenverwechsler(in)
Ich bin leidiger Besitzer eines bereits 2. 13900KS.
Der 1. wollte nach ein paar Wochen nicht mehr - Garantie von Intel abgelehnt.
1. Ich war nicht der, der das Teil im Laden gekauft hat.
2. Metallwärmeleitpaste lässt sich nicht entfernen, somit die Bezeichnungen nicht eindeutig erkennbar.
Garantieablehnung ohne Einsendung.
Vor ein paar Tagen hat der 2. 13900KS aufgegeben - vermute ich.
Beim vorherigen habe ich alles ausgetauscht.
RAM, NVME, Mainboard und zuletzt die CPU.
Dann lief alles ein paar Wochen wieder, und jetzt geht gar nichts mehr.
Kein OC, nur XMP.
i9 13900KS
Gigabyte Gaming X AX
Kingston Fury Renagade RGB DDR5-6000 128GB
Erst ist ein Programm immer öfter abgekackt, das 24/7 lief, dann Windows, hatte mich dann zu entschlossen ein Windows Inplace-Upgrade zu machen, das lief erstmal, die nächste Version, die dann per Windows Update kam, brach bei der Installation immer ab.
Die Entscheidung Windows clean neu zu installieren machte es nicht besser.
Alle Windows-Partitionen gelöscht - das war's dann gewesen.
Windows liess sich nicht neu installieren. Immer wieder Abbruch mit Bluescreen. Dann wurde die Nvme nicht mehr angezeigt - auch im UEFI nicht. Erst nach komplettem Shutdown.
Erstmal konnte ich Windows noch von einer externen Nvme starten - geht nicht mehr.
Partitionsmanager von USB beim Start - funktioniert nicht mehr.
Was mach ich nun?
Hab auch den Prozessor gebraucht gekauft.
Der 1. wollte nach ein paar Wochen nicht mehr - Garantie von Intel abgelehnt.
1. Ich war nicht der, der das Teil im Laden gekauft hat.
2. Metallwärmeleitpaste lässt sich nicht entfernen, somit die Bezeichnungen nicht eindeutig erkennbar.
Garantieablehnung ohne Einsendung.
Vor ein paar Tagen hat der 2. 13900KS aufgegeben - vermute ich.
Beim vorherigen habe ich alles ausgetauscht.
RAM, NVME, Mainboard und zuletzt die CPU.
Dann lief alles ein paar Wochen wieder, und jetzt geht gar nichts mehr.
Kein OC, nur XMP.
i9 13900KS
Gigabyte Gaming X AX
Kingston Fury Renagade RGB DDR5-6000 128GB
Erst ist ein Programm immer öfter abgekackt, das 24/7 lief, dann Windows, hatte mich dann zu entschlossen ein Windows Inplace-Upgrade zu machen, das lief erstmal, die nächste Version, die dann per Windows Update kam, brach bei der Installation immer ab.
Die Entscheidung Windows clean neu zu installieren machte es nicht besser.
Alle Windows-Partitionen gelöscht - das war's dann gewesen.
Windows liess sich nicht neu installieren. Immer wieder Abbruch mit Bluescreen. Dann wurde die Nvme nicht mehr angezeigt - auch im UEFI nicht. Erst nach komplettem Shutdown.
Erstmal konnte ich Windows noch von einer externen Nvme starten - geht nicht mehr.
Partitionsmanager von USB beim Start - funktioniert nicht mehr.
Was mach ich nun?
Hab auch den Prozessor gebraucht gekauft.
Sich mit den Intel-Herstellervorgaben beschäftigen. Die sehen DDR5-3600 für einen stabilen Betrieb vor bei dieser RAM-Kombination.
deadletters
Schraubenverwechsler(in)
Hilft nur leider nichts.
Allein bis der Mainboard Bildschirm auftaucht benötigt im Moment ca 3 Minuten.
Mit XMP1 also DDR5-4800 lief es wochenlang tadellos.
Deaktivierung von XMP und auf DDR5-3600 setzen bringt keine Veränderung.
Allein bis der Mainboard Bildschirm auftaucht benötigt im Moment ca 3 Minuten.
Mit XMP1 also DDR5-4800 lief es wochenlang tadellos.
Deaktivierung von XMP und auf DDR5-3600 setzen bringt keine Veränderung.
Die lange Boot-Verzögerung wird DDR5-Training sein. Wenn das System beim letzten Start davor abgestürzt ist oder du UEFI-Änderungen vorgenommen hast, ist das normal. Wenn nicht, wäre es ein Hinweis darauf, dass (noch) was anderes nicht stimmt, womit die CPU-Kerne gar nichts zu tun haben.
Gebrauchtkauf ist natürlich immer ein Problem. Normalerweise wäre man nach so kurzer Zeit entspannt in der Gewährleistung und der Händler hätte das Problem. Einen erneuten Versuch bei Intel würde ich dennoch starten – die haben ja kürzlich aufgefordert, bei Problemen Kontakt aufzunehmen.
Um bis dahin überhaupt ein nutzbares System zu haben, kannst du zunächst den Maximaltakt spürbar senken und ggf. ein leichtes Spannungs-Offset ergänzen. TVB aus, Boost-Takt auf den ersten zwei Kernen von 5,7 GHz auf z.B. 5,4 oder 5,2 runter (Allcore Boost sollte keine separate Absenkung brauchen), Uncore-/Cache-Takt auch um 200 MHz unter default (@PCGH_Dave: Wo liegt der beim 13900K normalerweise?) und im Gegenzug +0,05 bis +0,1 V Offset Kern-/Cache-Spannung wären mein erster Versuch. Ein paar Watt weniger beim Power Limit können auch nicht schaden. Das alles in der Annahme, dass das beschriebe, große Degradationsproblem vorliegt. Wenn das Muster von den Produktionsfehlern ("Oxidation") betroffen ist oder einfach eine komplett andere Macke hat (Netzteil bliebe noch auszutauschen^^), dann führen die Vorschläge natürlich ins Leere. Aber bei dem großen Problem sieht alles nach einer Degradation der CPUs durch zu hohe Spannungen bei zu hohen Temperaturen im Laufe der Zeit aus. Gemessen an dem so reduzierten Taktpotenzial führt der Betrieb @Default dann zu den gleichen Fehlern wie Übertaktung und braucht auch die gleichen Gegenmaßnahmen wie OC-Instabilitäten.
Nur darf man halt nicht einfach die absolute Spannung hochschrauben, wie das einige der ersten Gegenmaßnahmen-UEFIs es versucht haben, weil man damit erst Recht in der Zone weiterer Degradation landet und die CPU bald gar nicht mehr zu gebrauchen ist. Also erst durch Multiplikator- oder/und Power-Limit-Drosselung niedrigere Taktzustände erzwingen und dann die Spannung für diese leicht anheben – die Werks-VID-Kurve ist natürlich auf ganzer Strecke nicht mehr passend, aber wenn man die normalerweise mit Stromspar-Spannungen versorgten Betriebszustände mit normal-niedrigen Werten nutzt, sollte man wieder stabil unterwegs sein und absolut betrachtet unter dem Bereich weiterer Schädigung bleiben.
Aus Interesse: Wie lang hattest du die CPU im Einsatz, mit was für Settings lief sie (PL1, PL2, ICCmax, TVB oder, wenn "auto": Mit welchem UEFI?), welche waren die überwiegend genutzten Anwendungen und welche diejenige, die als erste Abstürzte? Und hast du irgendwelche Hinweise auf den Betrieb beim Vorgänger?
Wir haben weiterhin einen Mangel an Details zu derartigen Fällen und können sie weder nachstellen noch die Ursachen vollständig nachvollziehen.
Gebrauchtkauf ist natürlich immer ein Problem. Normalerweise wäre man nach so kurzer Zeit entspannt in der Gewährleistung und der Händler hätte das Problem. Einen erneuten Versuch bei Intel würde ich dennoch starten – die haben ja kürzlich aufgefordert, bei Problemen Kontakt aufzunehmen.
Um bis dahin überhaupt ein nutzbares System zu haben, kannst du zunächst den Maximaltakt spürbar senken und ggf. ein leichtes Spannungs-Offset ergänzen. TVB aus, Boost-Takt auf den ersten zwei Kernen von 5,7 GHz auf z.B. 5,4 oder 5,2 runter (Allcore Boost sollte keine separate Absenkung brauchen), Uncore-/Cache-Takt auch um 200 MHz unter default (@PCGH_Dave: Wo liegt der beim 13900K normalerweise?) und im Gegenzug +0,05 bis +0,1 V Offset Kern-/Cache-Spannung wären mein erster Versuch. Ein paar Watt weniger beim Power Limit können auch nicht schaden. Das alles in der Annahme, dass das beschriebe, große Degradationsproblem vorliegt. Wenn das Muster von den Produktionsfehlern ("Oxidation") betroffen ist oder einfach eine komplett andere Macke hat (Netzteil bliebe noch auszutauschen^^), dann führen die Vorschläge natürlich ins Leere. Aber bei dem großen Problem sieht alles nach einer Degradation der CPUs durch zu hohe Spannungen bei zu hohen Temperaturen im Laufe der Zeit aus. Gemessen an dem so reduzierten Taktpotenzial führt der Betrieb @Default dann zu den gleichen Fehlern wie Übertaktung und braucht auch die gleichen Gegenmaßnahmen wie OC-Instabilitäten.
Nur darf man halt nicht einfach die absolute Spannung hochschrauben, wie das einige der ersten Gegenmaßnahmen-UEFIs es versucht haben, weil man damit erst Recht in der Zone weiterer Degradation landet und die CPU bald gar nicht mehr zu gebrauchen ist. Also erst durch Multiplikator- oder/und Power-Limit-Drosselung niedrigere Taktzustände erzwingen und dann die Spannung für diese leicht anheben – die Werks-VID-Kurve ist natürlich auf ganzer Strecke nicht mehr passend, aber wenn man die normalerweise mit Stromspar-Spannungen versorgten Betriebszustände mit normal-niedrigen Werten nutzt, sollte man wieder stabil unterwegs sein und absolut betrachtet unter dem Bereich weiterer Schädigung bleiben.
Aus Interesse: Wie lang hattest du die CPU im Einsatz, mit was für Settings lief sie (PL1, PL2, ICCmax, TVB oder, wenn "auto": Mit welchem UEFI?), welche waren die überwiegend genutzten Anwendungen und welche diejenige, die als erste Abstürzte? Und hast du irgendwelche Hinweise auf den Betrieb beim Vorgänger?
Wir haben weiterhin einen Mangel an Details zu derartigen Fällen und können sie weder nachstellen noch die Ursachen vollständig nachvollziehen.
ΔΣΛ
PCGH-Community-Veteran(in)
Früher oft, aber bei Sockel 1700 nicht mehr so oft, vor allem da die meisten K-CPUs bei Empfehlungen wollten, aber Brechstange empfehle ich schon lange nicht mehr. Bei Sockel 1700 habe ich früher öfter CPUs ohne K empfohlen, wie den 12400F. Hier ist überwiegend Ryzen-Land, aus guten und verständlichen Gründen, da hier überwiegend Nerds unterwegs sind, die überwiegend nicht Empfehlungsresistent und für Faktenbasierte Argumente offen sind. Es gibt natürlich weiterhin die Jahrzehnte Werbeindoktrinierten Intelianer, erst kürzlich ist mir einer in einem anderen Forum begegnet, der Ryzen ablehnte weil es in den tiefen des Netztes wenn man ganz genau sucht Probleme geben soll, die er nicht nennen wollte, wo er die Probleme bei Intel bei Verbrauch, Temperaturen und dem ganzen Ausfallzeugs wohlwollend ignorierte, bei solchen Leuten kann man nur lachen. Früher hatte ich selbst nur Intel CPUs, mehr als 20 Jahre, also vor Ryzen 3000, aber selbst ich kann noch was lernen, jetzt kommt mir nur noch das bessere in den Rechner - egal ob da AMD, Intel oder Klobrille drauf stehtHast Du das denn jemals getan?
deadletters
Schraubenverwechsler(in)
Sorry, dass ich mich erst jetzt wieder melde, aber das Ganze ist eine längere Story.
Ich mein, eigentlich hab ich kein Plan von irgendwas in der Richtung, nur durch eigene Aneignung, Forschung, testen, lesen etc. .
Bin von Beruf her Erzieher, hab es allerdings in der IT-Materie immerhin so weit gebracht, dass wenn es in meinem Betrieb um IT geht, sich selbst die Chef-Etage an mich wendet.
Wenn ich selbst nicht weiter weiss, bin ich aufgeschmissen, ohne sachkundige Unterstützung aus'm Netz.
Hab in jüngeren Jahren versucht, an eine IT-Ausbildung zu kommen, war aber scheinbar zu blöd dazu. Die gehen ja auch einfach nur nach Zeugnis, und wenn bei Mathe ne 4 drin steht ist's halt gelaufen, egal was die Hintergründe sind und an IT-Verständnis da ist oder eben auch nicht.
Damit möcht ich mich nicht gut hinstellen, sondern einfach nur mitteilen, dass es hier scheinbar kein fachkundiges IT-Personal zu geben scheint - scheinbar auch keine professionellen Experten.
Ich lebe deutlich ländlich und schalge mich mit maximalen DSL-Downstreams von 6,5MBit/s rum, und wenn es gut läuft kommen über das Mobilfunknetz 60Mbit/s rum, das stürtz schnell wieder auf 30 - 10 MBit/s runter. Verschiebt man das Smartphone um 2cm sind es möglicherweise plötzlich nur noch 0,2MBit/s. Dazu kommt es noch auf Wetterbedingungen, Uhrzeit und Tag an. Also für grössere Downloads - Hotspot vom'm Smartphone an, dann immer schön mehrere Speedtests auf'm Smartphone an verschiedenen Positionen/Stellen durchführen, gute Stelle gefunden, nicht anrühren und hoffen, dass nach 5 sec. die Lage noch passt und DL starten.
Wäre es zu meiner Erleichterung möglich, mir einfach zu schreiben, wo ich was finde und ändern muss?
Ich konnte zwischen 13900KS ganz klare Parallelen beobachten.
Selbes Muster, was Stabilität bis KO betrifft, daher für mich deutliches Indiz auf R.I.P. 13900KS Nr.2.
Pass acht, ich versuch vorne anzufangen, beschreibe die Problematik bei CPU 1/2 nur bedingt getrennt.
Angefangen hat es damit, dass ich mein PC nach X Jahren wieder in Betrieb nahm. Darin werkelte ein Gigabyte Board mit einem Intel Q6700. Um kurz zu bleiben: ging hobs.
Das Ganze habe ich wieder in Betreib genommen, da ich über den Chia Coin gestolpert bin, und mich dieser angefixt hat.
Am Anfang lief alles über mein Laptop.
Dann eben Umstieg auf alt-PC.
Da PC hobs, und ich immer schaue mir dann Komponenten zusammenzustellen, die ich nicht nach 2 Jahren schon wieder austauschen kann, bin ich eben auf den 13900KS gegangen, in der Hoffnung für die nächsten 10 Jahre ausgesorgt zu haben.
Als ich mit Chia begonnen habe, war dies noch CPU-hungrig.
Das heisst anfangs lief die erste 13er CPU viele, viele, viele Stunden mit 100% Auslastung.
Lief und lief und lief.
Die CPU-relevanten-Einstellungen liefen alle auf UEFI-Default, mit 64GB DDR5-6000 bei XMP3.
Ich glaube begonnen habe ich mit UEFI F4 oder F5.
Irgendwann, nach ich glaube zwischen 1,5 und 2 Monaten hat alles angefangen zu spinnen.
Als Erstes im Verdacht waren die Nvmes.
Es hat damit angefangen, dass das Erstellen der Dateien für Chia immer wieder abgebrochen ist.
Dann ist die Synchronisation der Blockchain immer wieder abgebrochen, und der Farmer stieg aus. Alles Mögliche hatte Fehlermeldungen. Windows war im Verlauf - ich weiss gerade nicht mehr wie diese Konsole heisst - voller Fehler, und es kam nach und nach zu mehr und mehr Bluescreens.
Wie geschrieben, ähnlicher Verlauf aktuell.
Unterschied:
CPU-Auslastung nur die ersten max. zwei Wochen viel auf 100%. Die Geschwindigkeit lag im Schnitt bei 4,5-4,6Ghz, auch bei der vorherigen CPU.
Mit der neuen CPU war so gut wie alles ausgetauscht.
Also CPU, MB, Nvmes, RAM, alles komplett getauscht. Windows 11 Pro clean installiert - alles, um möglichst jeden Fehler auszumerzen. Nur die HDDs sind geblieben.
Da bin ich mit UEFI F7 oder F8 eingestiegen.
Alles lief wieder wie es sollte, und rannte - alles ohne Probleme.
Nach ca 1-1,5Wochen, da ich in Kontakt mit jemandem aus einem anderen Forum bin, bin ich doch auf seine Empfehlung eingegangen, und von Nvme/CPU Datei-Erstellung auf GPU/Ram-Erstellung umgestiegen.
Somit wurde die CPU zumeist nur noch low-Level belastet.
Mit 64GB war ich dann unterdimensioniert. Somit ging ich nach ca einem Monat auf 128GB-Ram vom selben Typ - nur die Farbe ist anders.
Erstmal ging ich in die Rebootschleife, nach 2 Versuchen erinnerte ich mich an die Angaben von Gigabyte:
bei 4x Ram = 5000MT/s+ Stabilität abhängig von CPU. Somit runter auf XMP2 - alles läuft - stabil - FREUDE!
Nach ca. 1,5 Monaten begannen - nach alles neu und nach ca 1-2 Wochen 128GB Ram - die Probleme wieder. Das Dateierstellen über die GPU lief weiterhin fast ohne Probleme.
Nach 3-4 Wochen mehr Ram fing das absolute Chaos wieder an. Syncronisation der Blockchain fällt raus, Farmer stürzt ab, GUI von Chia hat dauern Fehler.
Dann ging es wieder los mit Abstürzen - Bluescreen etc.
Allein Checkdisk von der zweiten Partition der System Nvme brachte nach kurzer Zeit ein Bluescreen hervor.
Windows lässt sich nur noch per command herunterfahren, nicht mehr über das Startmenü. Herunterfahren und Ruhezustand bewirken quasi abmelden und neu anmelden.
Windows Update auf neue Version schlug fehl, dism ... + sfc ... rettete kurzzeitig was - inplace upgrade brachte auch nochmal kurz was, dann schlug alles Mögliche fehl.
Bei den Chekdisk Versuchen stieg dann auch die System-Nvme aus - selbst im UEFI nicht mehr angezeigt.
Start von USB-Stick erstmal noch möglich.
Nach PC-komplett-Shutdown System Nvme wieder da.
Mehrere Versuche von Win-Install auf System-Nvme - zuvor alle Win-Partitionen gelöscht - jedes Mal fehlgeschlagen.
MiniTools Partitionsmanager lässt sich starten, Windows Installation lässt sich starten (bricht aber ab). Windows lässt sich von per USB angeschlossener Nvme starten - Bluescreens kommen nach geraumer Zeit.
Da geht jetzt nix mehr.
Ventoy startet, aber egal welches Image ich versuche - nix - ob gparted, MiniTool, Win install.
Auch ein Win-install-Stick hilft nicht.
Tote Hose.
Ich habe sobald ich gesehen habe, dass ein UEFI-Update vorhanden ist, dieses aufgespielt.
Aktuell ist F11c drauf, hatte mir erhofft - aber nicht daran geglaubt - dass es meine Probleme behebt - Satz mit X - war wohl nix.
Hoffe hab nichts vergessen.
PS.: die letzte überwiegende Zeit plätscherte die CPU einfach nur so mit, ohne grossartige Belastung, im Gegensatz zu der vorherigen CPU, die viel länger ausgelastet war.
Aber die Zeit bis Probleme auftauchten unterschied sich nach meiner Einschätzung nicht.
Hoffe, dass mit meinem Bericht nicht nur mir geholfen werden kann, sondern vielleicht lassen sich ja auch irgendwie in irgendeiner Form irgendwelche Erkenntnisse daraus heruaskristallisieren.
Vermute die CPU ist eh hops, da kann ich dann bei Bedarf einfach auch noch irgendwelche komische Dinge testen.
Solch eine lange Verzögerung hatte ich in der Form nie. Es benötigt eine ganze Weile, bis überhaupt der Bildschirm ein Signal bekommt, ist das Signal da, dauert es nochmals ewig. Ich kenne die Verzögerung durch UEFI-Änderungen etc., aber diese Dauer bis der MB Bildschirm da ist, ist aus meiner Sicht nicht normal, und von dem, was ich bisher erlebt hab, ein Anzeichen für einen Hardwaredefekt.
Ich mein, eigentlich hab ich kein Plan von irgendwas in der Richtung, nur durch eigene Aneignung, Forschung, testen, lesen etc. .
Bin von Beruf her Erzieher, hab es allerdings in der IT-Materie immerhin so weit gebracht, dass wenn es in meinem Betrieb um IT geht, sich selbst die Chef-Etage an mich wendet.
Wenn ich selbst nicht weiter weiss, bin ich aufgeschmissen, ohne sachkundige Unterstützung aus'm Netz.
Hab in jüngeren Jahren versucht, an eine IT-Ausbildung zu kommen, war aber scheinbar zu blöd dazu. Die gehen ja auch einfach nur nach Zeugnis, und wenn bei Mathe ne 4 drin steht ist's halt gelaufen, egal was die Hintergründe sind und an IT-Verständnis da ist oder eben auch nicht.
Damit möcht ich mich nicht gut hinstellen, sondern einfach nur mitteilen, dass es hier scheinbar kein fachkundiges IT-Personal zu geben scheint - scheinbar auch keine professionellen Experten.
Ich lebe deutlich ländlich und schalge mich mit maximalen DSL-Downstreams von 6,5MBit/s rum, und wenn es gut läuft kommen über das Mobilfunknetz 60Mbit/s rum, das stürtz schnell wieder auf 30 - 10 MBit/s runter. Verschiebt man das Smartphone um 2cm sind es möglicherweise plötzlich nur noch 0,2MBit/s. Dazu kommt es noch auf Wetterbedingungen, Uhrzeit und Tag an. Also für grössere Downloads - Hotspot vom'm Smartphone an, dann immer schön mehrere Speedtests auf'm Smartphone an verschiedenen Positionen/Stellen durchführen, gute Stelle gefunden, nicht anrühren und hoffen, dass nach 5 sec. die Lage noch passt und DL starten.
Ich war leider zu blöd aus meinem ersten Fehler zu lernen, und hatte gehofft einfach ein montags-Modell erwischt zu haben, oder sonste was.
Damit habe ich mich bisher noch überhaupt rein gar nicht beschäftigt, und muss schauen, ob ich die entsprechenden Punkte finde - mit einem gewissen Zeitaufwand bestimmt.
Wäre es zu meiner Erleichterung möglich, mir einfach zu schreiben, wo ich was finde und ändern muss?
Ich vermute, dieser Punkt ist recht erheblich.
Ich konnte zwischen 13900KS ganz klare Parallelen beobachten.
Selbes Muster, was Stabilität bis KO betrifft, daher für mich deutliches Indiz auf R.I.P. 13900KS Nr.2.
Pass acht, ich versuch vorne anzufangen, beschreibe die Problematik bei CPU 1/2 nur bedingt getrennt.
Angefangen hat es damit, dass ich mein PC nach X Jahren wieder in Betrieb nahm. Darin werkelte ein Gigabyte Board mit einem Intel Q6700. Um kurz zu bleiben: ging hobs.
Das Ganze habe ich wieder in Betreib genommen, da ich über den Chia Coin gestolpert bin, und mich dieser angefixt hat.
Am Anfang lief alles über mein Laptop.
Dann eben Umstieg auf alt-PC.
Da PC hobs, und ich immer schaue mir dann Komponenten zusammenzustellen, die ich nicht nach 2 Jahren schon wieder austauschen kann, bin ich eben auf den 13900KS gegangen, in der Hoffnung für die nächsten 10 Jahre ausgesorgt zu haben.
Als ich mit Chia begonnen habe, war dies noch CPU-hungrig.
Das heisst anfangs lief die erste 13er CPU viele, viele, viele Stunden mit 100% Auslastung.
Lief und lief und lief.
Die CPU-relevanten-Einstellungen liefen alle auf UEFI-Default, mit 64GB DDR5-6000 bei XMP3.
Ich glaube begonnen habe ich mit UEFI F4 oder F5.
Irgendwann, nach ich glaube zwischen 1,5 und 2 Monaten hat alles angefangen zu spinnen.
Als Erstes im Verdacht waren die Nvmes.
Es hat damit angefangen, dass das Erstellen der Dateien für Chia immer wieder abgebrochen ist.
Dann ist die Synchronisation der Blockchain immer wieder abgebrochen, und der Farmer stieg aus. Alles Mögliche hatte Fehlermeldungen. Windows war im Verlauf - ich weiss gerade nicht mehr wie diese Konsole heisst - voller Fehler, und es kam nach und nach zu mehr und mehr Bluescreens.
Wie geschrieben, ähnlicher Verlauf aktuell.
Unterschied:
CPU-Auslastung nur die ersten max. zwei Wochen viel auf 100%. Die Geschwindigkeit lag im Schnitt bei 4,5-4,6Ghz, auch bei der vorherigen CPU.
Mit der neuen CPU war so gut wie alles ausgetauscht.
Also CPU, MB, Nvmes, RAM, alles komplett getauscht. Windows 11 Pro clean installiert - alles, um möglichst jeden Fehler auszumerzen. Nur die HDDs sind geblieben.
Da bin ich mit UEFI F7 oder F8 eingestiegen.
Alles lief wieder wie es sollte, und rannte - alles ohne Probleme.
Nach ca 1-1,5Wochen, da ich in Kontakt mit jemandem aus einem anderen Forum bin, bin ich doch auf seine Empfehlung eingegangen, und von Nvme/CPU Datei-Erstellung auf GPU/Ram-Erstellung umgestiegen.
Somit wurde die CPU zumeist nur noch low-Level belastet.
Mit 64GB war ich dann unterdimensioniert. Somit ging ich nach ca einem Monat auf 128GB-Ram vom selben Typ - nur die Farbe ist anders.
Erstmal ging ich in die Rebootschleife, nach 2 Versuchen erinnerte ich mich an die Angaben von Gigabyte:
bei 4x Ram = 5000MT/s+ Stabilität abhängig von CPU. Somit runter auf XMP2 - alles läuft - stabil - FREUDE!
Nach ca. 1,5 Monaten begannen - nach alles neu und nach ca 1-2 Wochen 128GB Ram - die Probleme wieder. Das Dateierstellen über die GPU lief weiterhin fast ohne Probleme.
Nach 3-4 Wochen mehr Ram fing das absolute Chaos wieder an. Syncronisation der Blockchain fällt raus, Farmer stürzt ab, GUI von Chia hat dauern Fehler.
Dann ging es wieder los mit Abstürzen - Bluescreen etc.
Allein Checkdisk von der zweiten Partition der System Nvme brachte nach kurzer Zeit ein Bluescreen hervor.
Windows lässt sich nur noch per command herunterfahren, nicht mehr über das Startmenü. Herunterfahren und Ruhezustand bewirken quasi abmelden und neu anmelden.
Windows Update auf neue Version schlug fehl, dism ... + sfc ... rettete kurzzeitig was - inplace upgrade brachte auch nochmal kurz was, dann schlug alles Mögliche fehl.
Bei den Chekdisk Versuchen stieg dann auch die System-Nvme aus - selbst im UEFI nicht mehr angezeigt.
Start von USB-Stick erstmal noch möglich.
Nach PC-komplett-Shutdown System Nvme wieder da.
Mehrere Versuche von Win-Install auf System-Nvme - zuvor alle Win-Partitionen gelöscht - jedes Mal fehlgeschlagen.
MiniTools Partitionsmanager lässt sich starten, Windows Installation lässt sich starten (bricht aber ab). Windows lässt sich von per USB angeschlossener Nvme starten - Bluescreens kommen nach geraumer Zeit.
Da geht jetzt nix mehr.
Ventoy startet, aber egal welches Image ich versuche - nix - ob gparted, MiniTool, Win install.
Auch ein Win-install-Stick hilft nicht.
Tote Hose.
Ich habe sobald ich gesehen habe, dass ein UEFI-Update vorhanden ist, dieses aufgespielt.
Aktuell ist F11c drauf, hatte mir erhofft - aber nicht daran geglaubt - dass es meine Probleme behebt - Satz mit X - war wohl nix.
Hoffe hab nichts vergessen.
PS.: die letzte überwiegende Zeit plätscherte die CPU einfach nur so mit, ohne grossartige Belastung, im Gegensatz zu der vorherigen CPU, die viel länger ausgelastet war.
Aber die Zeit bis Probleme auftauchten unterschied sich nach meiner Einschätzung nicht.
Hoffe, dass mit meinem Bericht nicht nur mir geholfen werden kann, sondern vielleicht lassen sich ja auch irgendwie in irgendeiner Form irgendwelche Erkenntnisse daraus heruaskristallisieren.
Vermute die CPU ist eh hops, da kann ich dann bei Bedarf einfach auch noch irgendwelche komische Dinge testen.
Zuletzt bearbeitet:
TE
TE
Das Video dazu ist jetzt auch da:
Für mehr Informationen besuche die Datenschutz-Seite.
Eingebundener Inhalt
Youtube
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst:
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.Für mehr Informationen besuche die Datenschutz-Seite.
@deadletters :
Ui, einfache Erklärung ist tricky, da ich gerade kein Gigabyte-System zur Hand habe. Ich hoffe, @PCGH_Dave (der öfters mit einem arbeitet), wird mich korrigieren. Im Prinzip werden dir, wie gesagt, sämtliche Einstellungen/Entscheidungen abverlangt, die man auch bei Overclocking beackern muss. Dort weil man eine CPU an ihrer Stabilitätsgrenze jenseits des Garantierten betreiben will, bei dir weil du vorerst einen Prozessor an seiner Stabilitätsgrenze nutzen musst, die leider (mittlerweile) unterhalb des Garantierten liegt. (Versuch trotzdem mal eine RMA bei Intel.)
Schritte im UEFI:
1. "F2" für den Advanced Mode, Reiter "Tweaker"
2. "Enhanced Multi-Core Performance": Aus
3. "Performance CPU Clock Ratio": Kann man allgemein oder per Core einstellen. Automatisch ist per Core mit bis zu 58 = 5,8 GHz bei Nutzung weniger Kerne. In der Annahme, dass deine Probleme aus Taktuntauglichkeit beliebiger Kerne resultieren, reicht ein einheitliches Limit für alle. Ich würde es mit 48 = 4,8 GHz probieren und bei Problemfreiheit in 0,1 GHz Schritten wieder hochgehen. Wenn du bei 4,8 GHz immer noch nicht stabil bist, liegt es wohl eher nicht am P-Core-Takt.
4. "Efficiency CPU Clock Ratio": Das gleiche, nur ausgehend von 4,3 runter auf 3,2 und ggf. wieder bis auf 4,0 hoch. (semi-stabile E-Kerne stören bei Teillast kaum, daher bei Anhebung sorgfältig testen!)
5. "Max Ring Ratio": Gleiches Spiel, nur für den Uncore-Bereich. Ich schätze mal, dass 4,0 sehr stabil sein sollte.
6. Weiter unten im Abschnitt "Voltage Control" entweder unter "Vcore Voltage Mode" oder bei "CPU Vcore" eine Option "offset" oder "adaptive" suchen und dann +0,05 oder, wenn das nicht hilft, +0,1 V einstellen. (Genauer Name und wo bei Gigabyte ist mir gerade entfallen, aber solange man ausgehend von 0,000 V ein "+" einstellen kann, dass irgendwo draufgeschlagen wird, ist man richtig.)
7. Unter "Internal L2Atom Override Mode" müsste es das gleiche nochmal geben, nur für die E-Kerne.
8. Im Untermenü "Advanced CPU Settings" die Optionen "Enhanced TVB" und "Intel ... Boost 3.0": Aus
9. An gleicher Stelle, viel weiter unten, "Turbo Power Limits" auf manuell und dann für PL1 (oder "long duration") 125 W und für PL2 (oder "short duration") maximal 253 W. Dazu mehr unten. Die "Core Current Limit"-Empfehlung liegt bei 307 A.
Anm.: Sollten die "Ratio"-Einstellungen direkt im Tweaker nicht den Erwartungen entsprechen, kann es sein, dass Gigabyte die entsprechenden Optionen auch unter \"Advanced CPU Settings"\"Turbo Ratios" versteckt. Ist, wie gesagt, lange her, dass ich auf einem Gigabyte getunt habe.
Zur Vorgeschichte: Sind die 4,5 bis 4,6 GHz der Mittelwert über alle Kerne oder nur für die P-Cores? Letzteres wäre extrem wenig und ein Zeichen für Überhitzung oder extreme Belastung. Ersteres noch einigermaßen normal, da 4,3 GHz auf 16 E-Kernen und 5,2 GHz auf 8 P-Kernen im Schnitt halt 4,6 GHz ergibt. Ich nehme mal an, du hast weder die Temperaturen noch die Kernspannung erfasst? Vielleicht kann @PCGH_Dave in einer freien Minute mal UEFI F4 und einen 13900K oder KS, falls der von @PCGH_Raff schon zurück ist, kombinieren. Ein Z790 Gaming X haben wir jedenfalls in der Redaktion und wenn seit meinem Test niemand dran war, ist F4 sogar noch drauf.
CPU-Mining-Dauerbetrieb ist jedenfalls ein gutes Beispiel für hohe, anhaltende Last, die etwaige riskante Auto-Configs voll ausreizen könnte. Mein Test-12900K ging zwar unter Prime 95 nicht über 210 W bei sehr zahmen 1,17 V, aber das lag nicht an korrekt gesetztem Power Limit ("4.096 W"), sondern an Gigabytes eigenem "energy efficient turbo", der die Taktraten einzelner Kerne begrenzt – und das je nach CPU-Modell durchaus unterschiedlich. Bislang haben wir da noch keine Fehlschläge beobachtet, aber gerade ein KS ist halt exotisch.
Ein anderer zu prüfender Aspekt wäre konkret diese Last. Weist du, ob sich mit aktuellen Mining-Clients noch vergleichbare erzeugen lässt oder gab es da Updates? Wir wollen ja keinen Reibach machen, aber derartiger Single-Use-Code kann extrem einseitig optimiert sein und dann z.B. SIMD-Einheiten radikal anders belasten als jedes Spiel. Durchbrennen dürfen die deswegen natürlich trotzdem nicht. Aber wenn ausgerechnet diese Lastverteilung in der Qualitätssicherung übersehen wurde, wäre es zumindest eine Teilentwarnung für Normalnutzer gegenüber einer allgemeinen Überlastung.
Ui, einfache Erklärung ist tricky, da ich gerade kein Gigabyte-System zur Hand habe. Ich hoffe, @PCGH_Dave (der öfters mit einem arbeitet), wird mich korrigieren. Im Prinzip werden dir, wie gesagt, sämtliche Einstellungen/Entscheidungen abverlangt, die man auch bei Overclocking beackern muss. Dort weil man eine CPU an ihrer Stabilitätsgrenze jenseits des Garantierten betreiben will, bei dir weil du vorerst einen Prozessor an seiner Stabilitätsgrenze nutzen musst, die leider (mittlerweile) unterhalb des Garantierten liegt. (Versuch trotzdem mal eine RMA bei Intel.)
Schritte im UEFI:
1. "F2" für den Advanced Mode, Reiter "Tweaker"
2. "Enhanced Multi-Core Performance": Aus
3. "Performance CPU Clock Ratio": Kann man allgemein oder per Core einstellen. Automatisch ist per Core mit bis zu 58 = 5,8 GHz bei Nutzung weniger Kerne. In der Annahme, dass deine Probleme aus Taktuntauglichkeit beliebiger Kerne resultieren, reicht ein einheitliches Limit für alle. Ich würde es mit 48 = 4,8 GHz probieren und bei Problemfreiheit in 0,1 GHz Schritten wieder hochgehen. Wenn du bei 4,8 GHz immer noch nicht stabil bist, liegt es wohl eher nicht am P-Core-Takt.
4. "Efficiency CPU Clock Ratio": Das gleiche, nur ausgehend von 4,3 runter auf 3,2 und ggf. wieder bis auf 4,0 hoch. (semi-stabile E-Kerne stören bei Teillast kaum, daher bei Anhebung sorgfältig testen!)
5. "Max Ring Ratio": Gleiches Spiel, nur für den Uncore-Bereich. Ich schätze mal, dass 4,0 sehr stabil sein sollte.
6. Weiter unten im Abschnitt "Voltage Control" entweder unter "Vcore Voltage Mode" oder bei "CPU Vcore" eine Option "offset" oder "adaptive" suchen und dann +0,05 oder, wenn das nicht hilft, +0,1 V einstellen. (Genauer Name und wo bei Gigabyte ist mir gerade entfallen, aber solange man ausgehend von 0,000 V ein "+" einstellen kann, dass irgendwo draufgeschlagen wird, ist man richtig.)
7. Unter "Internal L2Atom Override Mode" müsste es das gleiche nochmal geben, nur für die E-Kerne.
8. Im Untermenü "Advanced CPU Settings" die Optionen "Enhanced TVB" und "Intel ... Boost 3.0": Aus
9. An gleicher Stelle, viel weiter unten, "Turbo Power Limits" auf manuell und dann für PL1 (oder "long duration") 125 W und für PL2 (oder "short duration") maximal 253 W. Dazu mehr unten. Die "Core Current Limit"-Empfehlung liegt bei 307 A.
Anm.: Sollten die "Ratio"-Einstellungen direkt im Tweaker nicht den Erwartungen entsprechen, kann es sein, dass Gigabyte die entsprechenden Optionen auch unter \"Advanced CPU Settings"\"Turbo Ratios" versteckt. Ist, wie gesagt, lange her, dass ich auf einem Gigabyte getunt habe.
Zur Vorgeschichte: Sind die 4,5 bis 4,6 GHz der Mittelwert über alle Kerne oder nur für die P-Cores? Letzteres wäre extrem wenig und ein Zeichen für Überhitzung oder extreme Belastung. Ersteres noch einigermaßen normal, da 4,3 GHz auf 16 E-Kernen und 5,2 GHz auf 8 P-Kernen im Schnitt halt 4,6 GHz ergibt. Ich nehme mal an, du hast weder die Temperaturen noch die Kernspannung erfasst? Vielleicht kann @PCGH_Dave in einer freien Minute mal UEFI F4 und einen 13900K oder KS, falls der von @PCGH_Raff schon zurück ist, kombinieren. Ein Z790 Gaming X haben wir jedenfalls in der Redaktion und wenn seit meinem Test niemand dran war, ist F4 sogar noch drauf.
CPU-Mining-Dauerbetrieb ist jedenfalls ein gutes Beispiel für hohe, anhaltende Last, die etwaige riskante Auto-Configs voll ausreizen könnte. Mein Test-12900K ging zwar unter Prime 95 nicht über 210 W bei sehr zahmen 1,17 V, aber das lag nicht an korrekt gesetztem Power Limit ("4.096 W"), sondern an Gigabytes eigenem "energy efficient turbo", der die Taktraten einzelner Kerne begrenzt – und das je nach CPU-Modell durchaus unterschiedlich. Bislang haben wir da noch keine Fehlschläge beobachtet, aber gerade ein KS ist halt exotisch.
Ein anderer zu prüfender Aspekt wäre konkret diese Last. Weist du, ob sich mit aktuellen Mining-Clients noch vergleichbare erzeugen lässt oder gab es da Updates? Wir wollen ja keinen Reibach machen, aber derartiger Single-Use-Code kann extrem einseitig optimiert sein und dann z.B. SIMD-Einheiten radikal anders belasten als jedes Spiel. Durchbrennen dürfen die deswegen natürlich trotzdem nicht. Aber wenn ausgerechnet diese Lastverteilung in der Qualitätssicherung übersehen wurde, wäre es zumindest eine Teilentwarnung für Normalnutzer gegenüber einer allgemeinen Überlastung.
deadletters
Schraubenverwechsler(in)
Kann eine CPU eine Nvme killen?
Ist nicht die M2_1 über die Lanes direkt mit der CPU verbunden?
Ich hab nun doch noch die Haupt-Nvme getauscht, obwohl diese in Crystal zuletzt ohne Probleme aufgeführt wurde, da diese im UEFI überhaupt nicht mehr auftauchte.
Siehe da - Ladezeit zum Mainboard-Logo normal.
Windows lässt sich installieren.
Eine tote Nvme scheint alles um sich herum lahm zu legen - vermutlich in Verbindung mit den CPU-Zicken.
F4 hab ich schon eine ganze Weile nicht mehr drauf. Das war noch bei der ersten CPU.
Bei der zweiten bin ich glaube mit F8 gestartet, und wie geschrieben inzwischen F11c
Mir kam derletzt eine Idee:
Würde es euch (und dadurch auch mir ) weiterhelfen, wenn ich euch das Ganze zum Testen schicke?
Also MB mit CPU (ohne Lüfter), 128GB DDR5-6000, 3 Nvmes und Win 11 Pro + entsprechender Anwendungen.
Ich versuche es zu erklären:
BTC, etc. sind Proof-of-Work, das heisst ja es ist für eine Gewinchance stetige Hochleistung für das Mining gefordert.
Chia zählt zu den sogenannten Eco-Coins, und ist meines Wissens nach der grösste und bekannteste darunter. Der Rest der mir Bekannten sind quasi nur Nebenprodukte, und basieren auf dem Code von Chia. Chives war eine Weile auch im Wachstum, scheint aber gestorben zu sein - seit über einem Jahr kein Programm-Update. Basierte auch auf Chia, lief aber mit kleineren Plots.
Eco-Coins basieren auf Proof-of Stake, dies bedeutet, um so mehr belegte Speicherkapazität desto höher die Gewinnchance.
Es werden sogenannte Plots erstellt (nennt sich plotting). Früher lief dies über CPU-Auslastung + Nvme Belastung. D.h. viele Nvmes wurden innerhalb kurzer Zeit aufgeraucht.
Am Einfachsten liess sich dies über GUI bewerkstelligen, effizienter ist es jedoch per Kommandozeile. Es lässt sich in beiden Varianten die Auslastung beeinflussen, durch Angabe der verwendeten Threads. Ich bin stets auf die 32 Threads gegangen, sodass der CPU alles abverlangt wurde, was rauszuholen war.
Seit einer Weile ist GPU-Plotting (CUDA-Plotting - ich glaub das können nur die Nvidia-GPUs) integriert. Dabei wird die GPU und der RAM belastet. Die CPU spielt fast keine Rolle. Es können durch Kompression kleinere Dateien(Plots) erstellt werden.
Die CPU ist nötig für die Synchronisation, Berechnung und den Abgleich der Datenbank. Taktet dabei zwar immer wieder recht hoch, über 5,5 Ghz, ist aber in der Auslastung zumeist unter 50%.
Für das Farming an sich, ist so gut wie keine Rechenleistung notwendig. Als Farming wird der Vorgang bezeichnet, in dem die Inhalte der Plots mit dem aus der Datenbank verglichen werden. Was da wie ganz genau abläuft, bin ich mir auch nicht sicher.
Mit der 2. CPU habe ich nur ein paar Tage testweise die frühere Methode laufen lassen, dann aber nur noch Variante 2.
Nun, da der PC wieder läuft, habe ich nur die Datenbank Aktualisierung laufen lassen, und es zeichnet sich das gleiche Bild wie vor dem Nvme Austausch ab. Gleiches Bild wie bei der ersten 13900KS:
Datenbank aktualisiert sich, CPU-Auslastung ist ersichtlich, relativ hohe Taktrate, aber zumeist unter 50%.
Nach nur wenigen Minuten zeichnet sich ein deutlicher Einbruch im Auslastungsdiagramm ab. Die Taktrate fällt auf 1,*-2,*Ghz, und die Auslastung bricht absolut ein.
Damit ist die Synchronisation der DB stagniert.
Nichts geht mehr. Manchmal reicht es aus, das Programm neu zu starten, häufig bleiben aber die Anwendungsbestandteile im Hintergrund aktiv, und müssen über'n Tasmanager->Details einzeln beendet werden, bevor die nächsten paar Minuten sync möglich sind.
Bei der vorherigen CPU ist dann das Plotting nach Variante 1 auch immer abgebrochen, weshalb ich nach und nach das gesamte System - Nvme, dann RAM, danach Mainboard und zuletzt die CPU ausgetauscht hab.
Vor ich jetzt im UEFI so tief rumbastel - soll ich euch die Hardware schicken? Oder möchte jemand Mal per TeamViewer vorher reinschauen?
Ist nicht die M2_1 über die Lanes direkt mit der CPU verbunden?
Ich hab nun doch noch die Haupt-Nvme getauscht, obwohl diese in Crystal zuletzt ohne Probleme aufgeführt wurde, da diese im UEFI überhaupt nicht mehr auftauchte.
Siehe da - Ladezeit zum Mainboard-Logo normal.
Windows lässt sich installieren.
Eine tote Nvme scheint alles um sich herum lahm zu legen - vermutlich in Verbindung mit den CPU-Zicken.
OK, das hatt ich nicht erwähnt, den Advanced Mode ist aktiv.
Die 4,5-4,6 sind ist die Gesamtgeschwindigkeit bei Dauervolllast. Bei in kurzen Spitzen sehe ich auch Mal 5,8.
Kernspannung hab ich nicht beachtet, Temparatur bei normaler Belastung, wo die CPU so vor sich hin dümpelt ~40~45°C. Bei Volllast ~90-99°C
Wegen diesem Mainboard hab ich überhaupt auf den Artikel reagiert.
F4 hab ich schon eine ganze Weile nicht mehr drauf. Das war noch bei der ersten CPU.
Bei der zweiten bin ich glaube mit F8 gestartet, und wie geschrieben inzwischen F11c
Mir kam derletzt eine Idee:
Würde es euch (und dadurch auch mir
) weiterhelfen, wenn ich euch das Ganze zum Testen schicke?Also MB mit CPU (ohne Lüfter), 128GB DDR5-6000, 3 Nvmes und Win 11 Pro + entsprechender Anwendungen.
Mining ist, denke ich, eine nur bedingt zutreffende Bezeichnung.
Ich versuche es zu erklären:
BTC, etc. sind Proof-of-Work, das heisst ja es ist für eine Gewinchance stetige Hochleistung für das Mining gefordert.
Chia zählt zu den sogenannten Eco-Coins, und ist meines Wissens nach der grösste und bekannteste darunter. Der Rest der mir Bekannten sind quasi nur Nebenprodukte, und basieren auf dem Code von Chia. Chives war eine Weile auch im Wachstum, scheint aber gestorben zu sein - seit über einem Jahr kein Programm-Update. Basierte auch auf Chia, lief aber mit kleineren Plots.
Eco-Coins basieren auf Proof-of Stake, dies bedeutet, um so mehr belegte Speicherkapazität desto höher die Gewinnchance.
Es werden sogenannte Plots erstellt (nennt sich plotting). Früher lief dies über CPU-Auslastung + Nvme Belastung. D.h. viele Nvmes wurden innerhalb kurzer Zeit aufgeraucht.
Am Einfachsten liess sich dies über GUI bewerkstelligen, effizienter ist es jedoch per Kommandozeile. Es lässt sich in beiden Varianten die Auslastung beeinflussen, durch Angabe der verwendeten Threads. Ich bin stets auf die 32 Threads gegangen, sodass der CPU alles abverlangt wurde, was rauszuholen war.
Seit einer Weile ist GPU-Plotting (CUDA-Plotting - ich glaub das können nur die Nvidia-GPUs) integriert. Dabei wird die GPU und der RAM belastet. Die CPU spielt fast keine Rolle. Es können durch Kompression kleinere Dateien(Plots) erstellt werden.
Die CPU ist nötig für die Synchronisation, Berechnung und den Abgleich der Datenbank. Taktet dabei zwar immer wieder recht hoch, über 5,5 Ghz, ist aber in der Auslastung zumeist unter 50%.
Für das Farming an sich, ist so gut wie keine Rechenleistung notwendig. Als Farming wird der Vorgang bezeichnet, in dem die Inhalte der Plots mit dem aus der Datenbank verglichen werden. Was da wie ganz genau abläuft, bin ich mir auch nicht sicher.
Mit der 2. CPU habe ich nur ein paar Tage testweise die frühere Methode laufen lassen, dann aber nur noch Variante 2.
Nun, da der PC wieder läuft, habe ich nur die Datenbank Aktualisierung laufen lassen, und es zeichnet sich das gleiche Bild wie vor dem Nvme Austausch ab. Gleiches Bild wie bei der ersten 13900KS:
Datenbank aktualisiert sich, CPU-Auslastung ist ersichtlich, relativ hohe Taktrate, aber zumeist unter 50%.
Nach nur wenigen Minuten zeichnet sich ein deutlicher Einbruch im Auslastungsdiagramm ab. Die Taktrate fällt auf 1,*-2,*Ghz, und die Auslastung bricht absolut ein.
Damit ist die Synchronisation der DB stagniert.
Nichts geht mehr. Manchmal reicht es aus, das Programm neu zu starten, häufig bleiben aber die Anwendungsbestandteile im Hintergrund aktiv, und müssen über'n Tasmanager->Details einzeln beendet werden, bevor die nächsten paar Minuten sync möglich sind.
Bei der vorherigen CPU ist dann das Plotting nach Variante 1 auch immer abgebrochen, weshalb ich nach und nach das gesamte System - Nvme, dann RAM, danach Mainboard und zuletzt die CPU ausgetauscht hab.
Vor ich jetzt im UEFI so tief rumbastel - soll ich euch die Hardware schicken? Oder möchte jemand Mal per TeamViewer vorher reinschauen?
Einschicken ist zum jetzigen Moment vermutlich nicht sinnvoll. Es stehen ja neue AMD-CPUs an, da wird @PCGH_Dave ausgelastet sein.
Bezüglich Chia: Mein Fehler, ich hätte es besser wissen und von Farming statt Mining sprechen sollen. Es handelt sich übrigens nicht um Proof of Stake (das wären z.B. Ethereum oder Binance), sondern um Proof of Space, aber das ist für die Betrachtung unerheblich: Wenn die CPU dadurch geschädigt wurde, muss eine CPU-schädigende Last erzeugt worden sein. Die interessiert uns, nicht deren Name. Ich weiß aber nicht, ob es bei Chia irgendwelche Updates oder Änderungen im Netzwerk gab, welche die CPU-Belastung verändert haben? Immerhin ist es einige Zeit her, dass dein erster Prozessor geschädigt wurde und wir müssten deine damaligen Bedingungen nachstellen können.
Allgemein macht mich deine verfeinerte Schilderung eines verzögerten Problemeintritts aber stutzig. Hohe Temperaturen begünstigen zwar CPU-Rechenfehler, sodass diese "nach ein paar Minuten" wahrscheinlicher werden, aber gerade Sockel-1700-CPUs erhitzen sich normalerweise binnen Sekunden auf eine Temperatur nahe des Maximums und danach tut sich nur noch wenig. Garantiert nicht so viel, dass die Taktrate von 4,5-5,5 GHz auf 1-2 GHz fällt. Zur Gegenprobe kannst du meine Vorschläge trotzdem mal ausprobieren – bei einer an der Stabilitätsgrenze laufenden CPU sollten sie einen großen Unterschied machen. Wenn nicht, liegt vermutlich ein komplett anderes Problem vor. Zum beobachten Zeitfenster würden die Temperaturreserven von Spannungswandlerkühlungen passen – die sind bei diesem Board aber unverdächtig, solange es irgend einen Hauch von Luftbewegung im CPU-Umfeld gibt.
In Anbetracht der zuletzt eher GPU-lastigen Nutzung tippe ich daher auf die SSD: Sowohl die Wärmekapazität von M.2-Kühlern als auch die Kapazität des Pseudo-SLC-Caches vieler Laufwerke passen gut auf "ein paar Minuten". Von daher würde ich dich vor weiteren Analyseversuchen bitten, erst einmal mit nahezu reiner/überwiegender CPU-Last das Verhalten der CPU-Kerne über einen vergleichbaren Zeitraum zu prüfen (Cinebench, Prime 95 oder idealerweise eines der einschlägigen Unreal-Engine-Spiele, die eins für "die" Raptor-Lake-Problematik typisches Absturzverhalten zeigen). Als Gegenprobe sollte dann die NVME-SSD, die bislang für Farming genutzt wurde, durch eine andere (bevorzugt neue/bislang nur für andere Zwecke genutzte) getauscht werden. Gegebenenfalls reden wir hier einfach aneinander vorbei und du hast zum zweiten Mal einen Flash-Speicher totgeschrieben. Wurde das ursprünglich mit CPU 1 genutzte Laufwerk jemals mit CPU 2 ausprobiert, als diese "noch gut" war?
Ein weiterer, allerdings sehr unwahrscheinlich Punkt wäre ggf. noch der PCI-E-Controller in der CPU. M.2_1 und GPU laufen beide über den, aber wenn es dein System zulässt (Platzbedarf Grafikkarte) könntest du ausprobieren, was mit der gleichen SSD (oder einer neuen) und der gleichen Grafikkarte in vom PCH versorgten Slots (alle anderen) passiert. Ich halte es aber für unwahrscheinlich, dass dort ein Belastungsschaden vorliegt – zwar dürfte Chia ordentlich Datenverkehr zwischen beiden verursachen, aber Spiele schicken ja auch richtig viel von und zur Grafikkarte und da gab es nie Beschwerden.
Bezüglich Chia: Mein Fehler, ich hätte es besser wissen und von Farming statt Mining sprechen sollen. Es handelt sich übrigens nicht um Proof of Stake (das wären z.B. Ethereum oder Binance), sondern um Proof of Space, aber das ist für die Betrachtung unerheblich: Wenn die CPU dadurch geschädigt wurde, muss eine CPU-schädigende Last erzeugt worden sein. Die interessiert uns, nicht deren Name. Ich weiß aber nicht, ob es bei Chia irgendwelche Updates oder Änderungen im Netzwerk gab, welche die CPU-Belastung verändert haben? Immerhin ist es einige Zeit her, dass dein erster Prozessor geschädigt wurde und wir müssten deine damaligen Bedingungen nachstellen können.
Allgemein macht mich deine verfeinerte Schilderung eines verzögerten Problemeintritts aber stutzig. Hohe Temperaturen begünstigen zwar CPU-Rechenfehler, sodass diese "nach ein paar Minuten" wahrscheinlicher werden, aber gerade Sockel-1700-CPUs erhitzen sich normalerweise binnen Sekunden auf eine Temperatur nahe des Maximums und danach tut sich nur noch wenig. Garantiert nicht so viel, dass die Taktrate von 4,5-5,5 GHz auf 1-2 GHz fällt. Zur Gegenprobe kannst du meine Vorschläge trotzdem mal ausprobieren – bei einer an der Stabilitätsgrenze laufenden CPU sollten sie einen großen Unterschied machen. Wenn nicht, liegt vermutlich ein komplett anderes Problem vor. Zum beobachten Zeitfenster würden die Temperaturreserven von Spannungswandlerkühlungen passen – die sind bei diesem Board aber unverdächtig, solange es irgend einen Hauch von Luftbewegung im CPU-Umfeld gibt.
In Anbetracht der zuletzt eher GPU-lastigen Nutzung tippe ich daher auf die SSD: Sowohl die Wärmekapazität von M.2-Kühlern als auch die Kapazität des Pseudo-SLC-Caches vieler Laufwerke passen gut auf "ein paar Minuten". Von daher würde ich dich vor weiteren Analyseversuchen bitten, erst einmal mit nahezu reiner/überwiegender CPU-Last das Verhalten der CPU-Kerne über einen vergleichbaren Zeitraum zu prüfen (Cinebench, Prime 95 oder idealerweise eines der einschlägigen Unreal-Engine-Spiele, die eins für "die" Raptor-Lake-Problematik typisches Absturzverhalten zeigen). Als Gegenprobe sollte dann die NVME-SSD, die bislang für Farming genutzt wurde, durch eine andere (bevorzugt neue/bislang nur für andere Zwecke genutzte) getauscht werden. Gegebenenfalls reden wir hier einfach aneinander vorbei und du hast zum zweiten Mal einen Flash-Speicher totgeschrieben. Wurde das ursprünglich mit CPU 1 genutzte Laufwerk jemals mit CPU 2 ausprobiert, als diese "noch gut" war?
Ein weiterer, allerdings sehr unwahrscheinlich Punkt wäre ggf. noch der PCI-E-Controller in der CPU. M.2_1 und GPU laufen beide über den, aber wenn es dein System zulässt (Platzbedarf Grafikkarte) könntest du ausprobieren, was mit der gleichen SSD (oder einer neuen) und der gleichen Grafikkarte in vom PCH versorgten Slots (alle anderen) passiert. Ich halte es aber für unwahrscheinlich, dass dort ein Belastungsschaden vorliegt – zwar dürfte Chia ordentlich Datenverkehr zwischen beiden verursachen, aber Spiele schicken ja auch richtig viel von und zur Grafikkarte und da gab es nie Beschwerden.
deadletters
Schraubenverwechsler(in)
deadletters
Schraubenverwechsler(in)
Da ich den PC hauptsächlich für Chia, und wenn Chia stabil läuft auch Docker nutze, wäre es relativ egal, wie lange es dauert. Vielleicht würden sich nebenbei Gelegenheiten bieten.
Ob der PC nun bei mir ungenutzt rumsteht, oder Teile davon für eine Weile bei euch sind macht keinen Unterschied.
Chia bringt regelmässige Updates. Aus meiner Wahrnehmung gab es keine Belastungsveränderungen.
Die Datenbank hat sich von v1 auf v2 geändert, aber ich glaube, das war noch bevor ich den PC wieder in Betrieb genommen habe.
Anfangs habe ich das Chia rein über'n Laptop laufen lassen, und den PC dann zur Effizienzsteigerung, und remobilisierung des Laptops wieder in Betrieb genommen.
Der madmax plotter, den ich bei der 1. CPU und ein paar Tage bei der 2. genutzt hab, hat ewig kein Update bekommen.
Die zweite CPU hatte somit viel kürzere Zeit diese extreme Auslastung abbekommen, als die Erste.
Äh, bin mir jetzt nicht ganz so sicher, ob ich irgendwie was verbummelt hab, oder was auch immer, ist ja aber auch viel, oder ob ich die Rückfrage fehlinterpretiere, egal was. Ich glaub, ich hab auch etwas durcheinander geschrieben.
Also:
Die Temperaturen gehen bei Volllast - wie Du geschrieben hast - schnell, steil nach oben. Dies war der Fall beim Plotting unter CPU+Nvme Last.
Im Moment ist plotten erstmal nicht mehr dran, sondern das Ganze dahin zu bekommen, dass der Grundstein wieder gelegt ist und die Synchronisation läuft. Da dümpelt die Temperatur auch nur so vor sich hin, und ist nicht erwähnenswert. Ich hab es nicht mehr im Kopf, aber dürfte so bei ~45°C - trotz Luftkühlung - liegen.
Die Temperaturen haben keinen Einfluss auf die Abbrüche.
Aktuell hab ich den PC einfach nur im UEFI laufen, Raumtemperatur 26°C, CPU 40°C.
Spannung schwankt um die 1,05V
Nach dem Screenshot vom UEFI - soll ich dennoch an den Zahlen drehen?
Ich glaube nicht, dass wir aneinander vorbei reden. Es ist verdammt komplex.
Ich erinnere mich auch nicht mehr zu 100%.
Ich hatte bei der 1. CPU - wie auch jetzt - 3 Nvmes im Sytem. Letztendlich war davon keine wirklich totgeschrieben, sondern auf 0% runter.
Das System lief von anfang an auf einer Platte mit ich glaub nur noch 3% oder so, die ich vorher im Laptop hatte. Die 2 andern nutzte ich als Plotting Nvmes waren, beim Start nagelneu. Ich hab diese dann runter geschrieben, und bei ich glaube ca 30% fingen die Probleme an, mit immer häufigeren Abbrüchen. Dann ging ein RAM-Riegel hobbs, bei diesem wurden in CPU-Z und HWInfo nur noch Kryptische Zeichen angezeigt - Austausch - keine Besserung - Nvme austausch - ich weiss nicht mehr genau ob erst RAM oder erst Nvme - alles tutti neu. Dann hab ich die CPU aus'm Mainboard genommen, im Sockel war eine komische Stelle zu sehen - Austausch. Gleiches Spiel weiter. CPU Austausch - alles läuft.
Das erste System habe ich Ende Mai 23 das erste Mal gestartet, lief bis ca Mitte Juli oder so, dann hab ich ewig dran rum gemacht, bis ich ungefähr Mitte Mai das nächste komplett neue System hatte, das dann nach etwa gleicher Zeit ausgestiegen ist.
Mit dem Unterschied, dass ich von 64GB auf 128GB Ram hoch gegangen bin, von XMP1 (6000) auf XMP2 (5600) runter und die CPU Auslastung viel geringer war.
Beim Start mit CPU 2 waren die Nvmes quasi neu.
Je 2TB:
FireCuda 530
2x Lexar NM790
Auf einer der Lexar hatte ich zuletzt das System etc. diese steckte in M2A - also dem obersten Slot, diese hatte noch ca 90% - einfach tot.
Habe nun eine von den 0% Lexar NM800 Pro für's Sytem drin, aus dem, was ich inzwischen erprobt hab, spielen die 0% keine Rolle. Die Nvme ist aus meinem Stand vollkommen OK, die 0% heissen ja einfach bis dahin Garantiert der Hersteller dat Ding tut grundsätzlich, was es soll.
Prime95 kann ich mal laufen lassen, hab ich bei CPU 1 mal gemacht, das lief und lief und lief. Erst in einem späteren Stadium war nach irgendwas um die 24h der PC plötzlich neu gestartet.
Ich bin so absolut nicht der Gaming Typ. Gibt es irgend eines der Spiele kostenlos? und kann ich das dann einfach laufen lassen, oder muss ich das dann wirklich zocken?
Also:
Hab eben im UEFI gesehen, M.2_1 ist eigentlich M2A, aber das ist ja eigentlich wurscht.
Vielleicht versteh ich jetzt etwas falsch, aber meinst Du, ich soll die System Nvme, die aktuell in M2A steckt in einen anderen Slot packen?
Das System läuft ja aktuell wieder, über eine zwar 0% Nvme, aber es läuft.
Meine weiteren Tests waren:
Die ursprüngliche System-Nvme, in einem externen Gehäuse:
Nvme wird nicht erkannt, nur der Controller des Gehäuses.
PC betrieben über USB-Extern-Nvme mit Win 11 Pro - zwar auch eine 0% NM800Pro, aber aus meiner Sicht kein Einfluss - PC läuft, sync bricht ab. Gleiche Symptome.
Soll ich die 0% Nvme von Slot M2A noch auf eine der hochprzentigeren Nvmes in anderem Slot clonen und von dort aus starten?
Ich vermute, dass dies keinen Unterschied macht.
Ich hab da nichts dran gepfuscht. Als ich die erste CPU in dieses erste MB eingesetzt hab war das noch nicht, und als ich diese zum Nachschauen raus nahm sah es so aus.
Es sah in Realität aus, als wäre ein weisser Fleck im Sockel. Die Kontakte waren nicht verbogen oder so. Es sah fast aus wie Korrosion, Kalk oder Magnesium.
Ich weiss nicht, ob so etwas aus der CPU - an der hab ich nichts gesehen - die hab ich auch noch hier rumliegen - oder dem Sockel selbst austreten kann.
Anhänge
Zuletzt bearbeitet:
Ich schlage im Prinzip das klassische Austauchverfahren zur Fehlereingrenzung vor:
[CPU mit Mainboard mit RAM mit SSDs an Netzteil] macht Probleme in einer spezifischen Lastsituation, die vor allem SSDs belastet, in zweiter Stelle RAM und Mainboard, aber eigentlich kaum die CPU und damit auch nicht das Netzteil. Damit wäre die CPU eigentlich nicht der Hauptverdächtige und man muss die anderen Fehlerquellen durchprobieren.
- CPU: Gezielt eines der bereits als Raptor-Lake-Killer bekannten Szenarien ausprobieren, um den Fehler zu provozieren. Einen Überblick habe ich da auch nicht wirklich, sondern müsste diverse Artikel von @PCGH_Sven durchgehen und gucken, was wie bezogen werden kann. Der Gegentest wäre es, die CPU mit den weiter oben geschriebenen Einstellungen in einen stabileren Betriebsszustand zu versetzen und gucken, ob sich was am Fehlerverhalten ändern.
- SSDs: Kenne ich keine Stabilitätstests für, deswegen hilft leider nur Austausch entweder der SSD oder des gesamten Systems (=> SSD in einen anderen Rechner einbauen und die gleichen Aktionen ausprobieren). Wenn deine Probleme z.B. mit einem überhitzen Controller zusammenhängen oder damit, dass die Software drastische Einbrüche bei der Schreibrate bei überlaufendem SLC-Cache nicht verkraftet, dann muss das Laufwerk unter anderen thermischen Bedingungen betrieben werden oder gegen ein leeres getauscht. Laufwerke mit bereits vorgeschädigten Speicherzellen laut eigener Firmware würde ich dabei für Stabilitätstests mit Laufwerkzugriffen generell nicht nutzen. Wenn das Ding schon auf z.B. 30 Prozent degeneriert ist, mag es noch funktionieren und noch ein paar Reserve-Speicherbereiche übrig haben. Aber die Wahrscheinlichkeit, dass die Fehlerkorrektur Überstunden schiebt oder weitere Speicherzellen stillgelegt und Inhalte umkopiert werden müssen, ist groß. "Das System läuft" zählt als entschärfende Bewertung nur, wenn es komplett problemfrei arbeitet.
Aber dann hätten wir hier nichts zu diskutieren.
[CPU mit Mainboard mit RAM mit SSDs an Netzteil] macht Probleme in einer spezifischen Lastsituation, die vor allem SSDs belastet, in zweiter Stelle RAM und Mainboard, aber eigentlich kaum die CPU und damit auch nicht das Netzteil. Damit wäre die CPU eigentlich nicht der Hauptverdächtige und man muss die anderen Fehlerquellen durchprobieren.
- CPU: Gezielt eines der bereits als Raptor-Lake-Killer bekannten Szenarien ausprobieren, um den Fehler zu provozieren. Einen Überblick habe ich da auch nicht wirklich, sondern müsste diverse Artikel von @PCGH_Sven durchgehen und gucken, was wie bezogen werden kann. Der Gegentest wäre es, die CPU mit den weiter oben geschriebenen Einstellungen in einen stabileren Betriebsszustand zu versetzen und gucken, ob sich was am Fehlerverhalten ändern.
- SSDs: Kenne ich keine Stabilitätstests für, deswegen hilft leider nur Austausch entweder der SSD oder des gesamten Systems (=> SSD in einen anderen Rechner einbauen und die gleichen Aktionen ausprobieren). Wenn deine Probleme z.B. mit einem überhitzen Controller zusammenhängen oder damit, dass die Software drastische Einbrüche bei der Schreibrate bei überlaufendem SLC-Cache nicht verkraftet, dann muss das Laufwerk unter anderen thermischen Bedingungen betrieben werden oder gegen ein leeres getauscht. Laufwerke mit bereits vorgeschädigten Speicherzellen laut eigener Firmware würde ich dabei für Stabilitätstests mit Laufwerkzugriffen generell nicht nutzen. Wenn das Ding schon auf z.B. 30 Prozent degeneriert ist, mag es noch funktionieren und noch ein paar Reserve-Speicherbereiche übrig haben. Aber die Wahrscheinlichkeit, dass die Fehlerkorrektur Überstunden schiebt oder weitere Speicherzellen stillgelegt und Inhalte umkopiert werden müssen, ist groß. "Das System läuft" zählt als entschärfende Bewertung nur, wenn es komplett problemfrei arbeitet.
Aber dann hätten wir hier nichts zu diskutieren.
deadletters
Schraubenverwechsler(in)
Moin,
kann gerade leider nichts testen, musste nach Holland in Urlaub.
1.
Die Synchronisation der Datenbank belastet das System nur sehr wenig.
2.
Finde ich es sehr komisch, dass nach Austausch aller entsprechenden Komponenten, sich das System im Verlauf genau gleich verhält.
Mit dem Unterschied, dass mir bei dem System nach dem Komplettaustausch, eine noch sehr gut erhaltene Nvme komplett kaputt ging.
Klar, kann wenn ich zurück bin, das Ganze zum Test einfach auf eine noch bessere erhaltene Nvme klonen.
Vielleicht ist bis dahin auch das BIOS Update da, möglicherweise bringt es ja etwas. Die Hoffnung stirbt zuletzt.
kann gerade leider nichts testen, musste nach Holland in Urlaub.
1.
Die Synchronisation der Datenbank belastet das System nur sehr wenig.
2.
Finde ich es sehr komisch, dass nach Austausch aller entsprechenden Komponenten, sich das System im Verlauf genau gleich verhält.
Mit dem Unterschied, dass mir bei dem System nach dem Komplettaustausch, eine noch sehr gut erhaltene Nvme komplett kaputt ging.
Klar, kann wenn ich zurück bin, das Ganze zum Test einfach auf eine noch bessere erhaltene Nvme klonen.
Vielleicht ist bis dahin auch das BIOS Update da, möglicherweise bringt es ja etwas. Die Hoffnung stirbt zuletzt.
Ähnliche Themen
- Gesperrt
