Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
@Tatilica How did you come to the 593 MHz LCLK? I guess you didn't roll the dice?
And what's the teory behind it? The possible range of LCLK seems huge. But what's the effect of a low or high and how to define and how to validate values?
Add
Oh, I also founf the 593 here, where Veii talked about something, feels like mixing Ryzen and Radeon topics.
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Tatilica How did you come to the 592 MHz LCLK? I guess you didn't roll the dice?
And what's the teory behind it? The possible range of LCLK seems huge. But what's the effect of a low or high and how to define and how to validate values?
Add
Oh, I also founf the 593 here, where Veii talked about something, feels like mixing Ryzen and Radeon topics.
Yeah, precisely from here, where @Veii by his grace was found LCLK behavoir in ZenPTMonitor, and as you can see 592 is everywhere🤫
And 60 it's plenty enough A for EDC to see even more FPS in CP2077, with same Phoenix 4070 max. out 1440p High/Ultra settings + RayT psycho
Das naheliegendste Beispiel wäre RDNA2.
Kaum zu unterscheiden von Zen. Andere (soft)IP Blöcke, weniger eigene Clocks (Arten) aber eigentlich, kaum zu unterscheiden.
Yep, 2021 ~ eigentlich 2020, musste lügen.🤭
Aber es dauerte recht lange bis alle anderen instabilen Peripherien im Grunde genommen "gelöst" wurden.
Ich vertraue dem weiterhin nicht, aber es müsste mittlerweile solide sein.
Credits for tool ~ XREHOPE, as always
LCLK recommended is 310-610, but may cause sound issues
X3D may be higher or lower by default. Unsure yet, but sure that SOCCLK is higher.
// AM5 is 150-2150??MHz
Tool still is not flawless (not every sensor is correctly labeled)
But seems current AGESA support remains.
You can run
280-593 on X3D, but i'm experimenting with it still // increased VDDG decreased SOC delta [jumping between 28.2-32ohm procODT], also experimenting tiny bit
High LCLK peak does increase arithmetic processing ability but can cause PCH soundloss. Doesn't seem to make too much IPC difference yet
For sub 2100 FCLK, absolutely not needed to be anywhere near 400MHz range. LCLK on (powersaving) ~ optimized LCLK for PCI 4.0 maybe off.
~location config for 1440p , i recommend that LUXX remakes it for 1080p~
I'm busy yesterday, today and tomorrow morning
But i'll check the messages later
Do not run this tool with Hydra, zentimings on autorefresh or HWinfo
They bother, this utilizes RSMU API & updates every 4-6ms, while HWInfo uses slow SMU consumer-api (every 30ms minimum)
Its low resource usage, but it still has UOPS overhead when benchmarking due to the pooling speed~
1,8V hab ich neuerdings keine Meinung mehr , denn (ich glaub ich habe das hier eh auch schon geposted):
Bei mir gingen 1,6V PLL nicht bei IF 1900/3800. Ich denke ich habe rausgefunden, wie es doch bei jedem geht - einfach die restlichen Spannungen entsprechend raufsetzen! So läuft es bei mir:
Beides stabil & WHEA frei. Jetzt ist nur noch die Frage: bringt es auch Vorteile? Keine Ahnung, aber ev testet ihr mit mir
Bedeutet übrigens nichts anderes, als dass mit der Eingangsspannung des PLL indirekt die einzelnen CPU Spannungen beeinflusst werden. Das erklärt dann, warum manche ihr Sys mit 1,9V PLL stabil bekommen, und es bei anderen keine Auswirkungen hat. Erstere waren wohl an der Stabilitätsgrenze mit vSOC/CCD/IOD/VDDP, andere haben da mehr Spielraum drin. Ev hilft es, WHEA 19 los zu werden. bin wieder beim Testen.
LCLK wurde eh schon diskutiert. Auto ist bei mir 593, wenn ich auch das min auf 593 fixiere, bootet der Rechner allerdings nicht. 450 haben mir auch nix gebracht bzgl WHEA, ev teste ich noch 300. Ist der IO-Takt, kann schon was helfen. LCLK DPM hab ich immer an, ansonsten greift das PPT Limit nicht und die Temp throttled erst bei 100° statt 90.
- Deine Ansichten zu SOC, CCD und IOD kenne und teile ich theoretisch, nur dass die von dir vorgeschlagenen Erhöhungen bei mir in einem WHEA-Regen enden.
isn't a simple solution, but it may show directions. And did. Wit your super high voltage I was able to see no WHEAs in gaming and light browsing - but this isn't a big thing.
And 3 cycles default-TM5 only showed 3 WHEAs. So the direction is not bad, but need further fine tuning.
Also was jetzt Sieht sehr nach meiner Erfahrung aus bzgl vSOC / CCD / IOD . VDDP kommt mir bissi hoch vor, kann trotzdem mit ~0,9V laufen, sogar stabiler.
Ein paar Beobachtungen:
- Ich hatte die fixen 593 MHz LCLK -> TM5 WHEAs...
- dann hab ich mal 280 bis 593 LCLK eingegeben -> Lightoom rendern WHEAs...
- Ich nutze schon sehr lange diesen Energiesparplan - und hier in der Regel immer beste Energieeinsparung.
- 593-610 LCLK erhöht. Da ich nich den ganten Tag TM5 spielen kann oder will, arbeite ich grad im Lightroom. 222 Fotos rausrender in "beste Energieeinsparung" -> 7 WHEAs
- 593-630 LCLK + "mittlere Einstellung Energieregler" und selbe 222 Bilder rausrendern -> 1 WHEA
- 593-630 LCLK + "beste Leistung" und selbe 222 Bilder rausrendern -> 0 WHEA
Das muss jetzt nichts heißen, aber ich fands berichtenswert. Auch explizit an euch grad:
- Hängen LCLK und Energiesparpläne potentiell irgendwie zusammen?
- Wie sollten bei IF2000 Energiesparoptionen generell gesetzt werden?
Hi alle, melde mich mit den Werten für mein 4x8 GB Setup zurück und würde mich über Optimierungstipps freuen
Meine Zeit als Schüler in diesem Spitzenthread liegt leider schon ein paar Jahre zurück und allzuviel Zeit ins tweaken will ich nicht nochmal ins investieren.
Viel scheint nicht zu gehen im Vergleich zum 2x8 GB Crucial Ballistix Setup (damals noch mit anderer CPU).
Bereits beim straffen von 3600 MHz gibt es Fehler. Frage mich, ob man da über 3600 MHz hinauskommt?
Das alte 2x8 GB Crucial Setting:
Das aktuelle 4x 8 GB Crucial & Corsair Setting:
Wieso ist der "Write"-Wert so schlecht? War doch immer ähnlich "Read" bisher?
Ich konnte den C5-Fehler mit USB BIOS FlashBack beheben und auf BIOS 1415 zurücksetzen. Alles funktioniert jetzt, ich werde langsam wieder auf BIOS 1905 stoßen und es als gut bezeichnen.
Aber ich sage, der default@1usmus_v3 ist kein scharfer Test!
Jetzt lass ich hinterer mal den extreme1@anta777 laufen und vermute, dass es mir da die Bilanz verhagelt.
@Tatilica But the point is, that default@1usmus_v3 isn't an appropriate test! I'm halfway trough extreme1@anta777 and I already see 4 WHEAs. Yesterday I played CP77 for about 90 min = 7 WHEAs. Same settings.
Maybe the default is ok for RAM-related errors, which it is aiming for. But in my opinion it's not enough for testing WHEAs.
@Tatilica But the point is, that default@1usmus_v3 isn't an appropriate test! I'm halfway trough extreme1@anta777 and I already see 4 WHEAs. Yesterday I played CP77 for about 90 min = 7 WHEAs. Same settings.
Maybe the default is ok for RAM-related errors, which it is aiming for. But in my opinion it's not enough for testing WHEAs.
Ist nicht Absolut@anta777 der neue Extreme? Ich hab immer Absolut verwendet, der scheint übrigens beim RAM mehr zu verzeihen als 1usmusv3. der anspruchsvoller war was CAD DrvStr bei 1T GDM off Setup 0-0-0 betrifft.
Interessant zu sehen, dass Extreme mehr WHEA provoziert. Würdest Du auch noch mit Absolut gegentesten? Da ich mit WHEA nicht so andere Kippe bin wie Du, sondern entweder trocken oder gleich ersauf, wäre das spannender in Deinem Setup
Aber ich sage, der default@1usmus_v3 ist kein scharfer Test!
Jetzt lass ich hinterer mal den extreme1@anta777 laufen und vermute, dass es mir da die Bilanz verhagelt.
Sollte er auch nie sein.
Er ist da um MCLK+MEM & minimal cache zu testen
Aber hat weder high IPC noch eine schere Lastart zu sein.
Testet eher mem communication.
Warscheinlich fliegen dir FFT (ebenfalls SSE workload)
Und N63 um die Ohren
// und womöglich auch Karhu bzw LinX Intel oder CB15 Extreme (Benchmate)
Wie bei Intel, wichtig~
Immer 2 Lastarten bei y-cruncher kombinieren,
Da Branch predictor + opcache ansonnsten alles vereinfachen.
Muss eine Random Last sein, von welcher man nichts lernen kann.
Es macht auch irgendwo Sinn, da WHEA für LCLK bzw GMI wenig mit der RAM kommunikation bzw dem MCLK zu tun haben.
Nahezu keine.
Beitrag automatisch zusammengeführt:
So wie ich die WHEAs jedoch kenne, denke ich nicht dass es eine Setup/Stresstest instability ist.
Schaue mal ob du beobachten kannst weswegen du WHEAs bekommst.
Ohne es als instabil zu sehen.
Etwas mehr log daten und die Art des WHEA 19 wäre auch nicht schlecht.
Es gibt verschiedene Arten von dem selben Error log.
Weswegen er erstellt wurde und nicht korrigiert wurde, wissen wir hat nichts mit dem OS zu tun
Aber man könnte nachschauen ob bei dir irgendein Wert hochgeschossen ist
Solltest du bei Win11 sein, lade ich gerne den Powerplan hoch.
Generell war balanced immer zu empfehlen, da custom PP overboost spikes erstellen.
C-State oder DF state wakeup spikes.
EDIT:
Den Instabilität = Instabilität
Package Throttle = Leistungsverlust
WHEA = WHEA
Drei unterschiedliche Dinge. #19 ist kein instability error. #18 schon
Ich denke nicht dass die CPU instabil ist.
Aber teste es mit y-cruncher. +72min~
Da müssen wir nicht weiterreden. Da brauch ich auch keinen weiteren Cycle. Wenn ich jetzt bei diesen hohen Spannungen bei Absolut so ein Durcheinander sehe, dann hat das alles keinen Wert und ich stell mir das beim nächsten Booten wieder auf 1900 um und gut. Und andersrum würde ich mir mit dem Ergebnis vom Default einfach nur selber was vorlügen, wo ich beim CP77 Spielen schon sehe, dass das nicht Bestand hat.
Ich hab mir die Details der WHEAs wie von Veii vorgeschlagen, angesehen. Das sind immer dieselben 19er,
@ApolloX : da sind wir offenbar einer Meinung, was die WHEA 19 Wall bei IF 1900 speziell beim 5800X3D angeht. Ich hab auch nochmal übers Wochenende alles mögliche eingestellt, und es wirft einfach ab 1933 schon Fehler ohne Ende. Ich find das "don´t give up" Mindset hier eh super, nur gibts da offenbar eine unterschiedliche Einschätzung der Erfolgswahrscheinlichkeit. Ich schätze die so bei ~5% ein bei ein paar Monaten Test-Aufwand nebenbei, auf Basis der wenigen mir bekannten Erfolgsmeldungen >1900. Das isses mir nicht mehr wert, und ich denke das ist eine fair gesetzte Erwartungshaltung
Ich kann dazu nicht viel anmerken.
Den die Entscheidung trifft jeder für sich.
Aber ihr urteilt zu schnell.
Auf zu simpler basis.
Die Community welche das mitließt, gibt dann genau so schnell auf, da zu schnell zu einem "entschluss" gesprungen wird.
Dazu muss ich nicht Urteilen, oder die Entscheidung beinflussen.
Jeder für sich.
Bloß finde ich, und darf dazu meine Meinung äußern,
Dass ihr ungenügend Daten presentiert und die bedeutung der Sensorlogs weiterhin komplett verfehlt.
Als ob man gegen eine Wand spricht.
// EDIT: Es kann auch sein dass ich das als seriöse Arbeit sehe, aber ihr nur Spaß haben möchtet somit entschuldige meinerseits erneuert.
Ob man diese Äußerung mag, oder sie für feindlich ansieht. So sehe ich das momentan.
Ungenügende Arbeit um überhaupt weiterkommen zu können.
Aber das ist ok, den die Zeit ist kostbar und RL ist sehr wichtig
Aber ja,
Ihr gebt zu schnell auf und basiert Daten auf "ja/nein"
Aber nicht auf "wieso/was bedeutet das was ich auslese".
Das finde ich recht schade.
Viel Glück weiterhin~
Bitte arbeitet etwas genauer das nächste mal.
Ihr springt weiterhin viel zu schnell zu einem Entschluss, ohne das "wieso" herrausfinden zu können. Geblendet von "ja/nein unstabil".
Wir alle wussten schon dass es für viele Nutzer nicht log-frei ist. Weiterhin ohne Reports "wieso".
Mit Luft kann ich so sehr ich es auch versuche, leider nichts anfangen und somit auch nicht helfen.
Mehr sollte ich dazu nicht sagen. 🙇♂️
Es macht mich jedoch etwas traurig, dass man anscheinend es weiterhin nicht versteht bzw mich verstehen kann.
Da man sich auf dem falschem fokusiert, welches ich schon das 4. mal erwähne.
Als ob man sich Mühe gibt es nicht verstehen zu wollen;
Ich kann es nicht verstehen, aber muss es auch nicht
Tut mir leid dass ich störe~
ich glaube, das Problem liegt einfach darin, dass wir alle zu wenig von der ganzen Materie verstehen und obendrein absolut nicht wissen, welche Einstellungen was beeinflussen und was man parallel zusammen ändern muss. Es gibt keine Richtwerte und man tapt einfach im dunkeln.
Ich hätte auch Lust, mich damit zu befassen, aber es ist sehr schwer dir zu folgen, weil ich viele Sachen einfach nicht verstehe.
Trotzdem Hut ab, für deine Arbeit und die Lust, dein Wissen mit uns zu teilen.
Es macht mich traurig, doch schon.
Den besser werde ich es nicht erklären können, besonders auf deutsch.
Aber was wirklich die Motivation limitiert,
Ist dass man sich nicht mal die mühe macht , es zu tracken.
Hauptpunkt wäre nur das.
Dass man nicht genau verstehr was Windows einem Ausspuckt und sich nicht die Zeit nehmen kann den verlinkten OCN thread durchzulesen.
Ok, zeit ist kostbar.
So fühle ich es.
Womöglich liege ich falsch, aber so ließt es sich.
Solange man sich auf das MemOC thema fokusiert und FCLK davon nicht trennt.
Solange man weder die Windows logs in Verbose beobachtet noch beginnt darin zu forschen was X Boardpartner eingestellt hat
Solange man weiterhin nur sturr den Ram anschaut und garantiert dem Package Throttle Problen verfällt,
Wird man das Problem niemals beseitigen können.
ich weiß nicht.
Ich lasse euch mal in Ruhe, und geb dem Zeit.
Womöglich erwarte ich einfach zu viel und man sieht es hier als JustForFun, an
Das MemOC ist absolut nicht das Problem, mein RAM kann auch 4533 2:1, no problem.
Das Package Throttle Problem ist auch kein Problem, da man es ausschalten kann. damit ist man WHEA free und mein 5900X ist mit FCLK 1900-1933-1966 gleich schnell ohne instabil zu werden. Selbst FCLK 2000 sind nie instabil gewesen, sind aber langsamer, als alle anderen Einstellungen. Alle settings 1:1 und 2:1 getestet.
Den Link zum OCN thread habe ich leider nicht gesehen, sonst hätte ich längst dort gelesen, sorry dafür.
Ich werde die letzten paar seiten nochmal lesen und versuchen Daten zu liefern.
Im WHEA-Suppressor thread wurde viel diskutiert was die einzelnen logs den eigentlich bedeuten.
Es wird mit SiSoftware Sandra Inter-Thread getestet, bzw wurde eine eigene test suite entwickelt.
Und mit ZenPTMonitor beobachtet
HWInfo benützt keiner mehr wenn man diese Tools hat und Windows erlaubt Verbose zu loggen.
Das ist einer der effekte von Package Throttle.
Es behält die stabilität bis zu X, jedoch nicht für immer.
Memtests spielen aber eigentlich keine Rolle.
Es ist nicht der UCLK.
@Veii Nix zu entschuldigen, im Gegenteil - toll dass es Leute wie Dich gibt, klar einige Levels weiter als ich Nur bitte wirf mir nicht vor, dass ich mit ~95% vom Erreichbaren zufrieden bin. ~95% die mich in Summe ~1 Jahr einen Teil meiner Freizeit gekostet haben, das letzte ~1% (3800 1T GDM off ohne Setup) wieder ~3 Monate (bringt übrigens praktisch nix, fühlt sich nur gut an ). Ich bin durchaus Purist mit Forschergeist, und mag Optimierung zum Selbstzweck, aber wenn ich 5% zusätzlich mit gefühlten 5% Erfolgswahrscheinlichkeit bekomme, da bin ich zur Zeit einfach nicht dabei. Auch nicht bei wiederholten Versuchen, mich bei der Ehre zu packen Ich nutze die Zeit lieber, mit 1-3 Posts andere User auf diese ~95% zu bringen, was auch oft gelingt. Das kostet die dann Tage statt Monate, super. Wenn sie weiter wollen, haben sie Dich
Und nochmal, ich stehe ja auch ganz offen dazu - ich steh bei ~95% vom Erreichbaren, Du bei ~100. Vielleicht ist´s in paar Monaten bei mir entspannter und ich steige nochmal in die Log-Thematik ein, bis dahin verlasse ich mich auf @unifyx und @ApolloX , die mir dann hoffentlich schon in 1-3 Posts sagen können was zu tun ist nach der Versuchsorgie mit Dir
Maybe~
Ich weiß ApolloX kann es besser~
Das arme TM5, soo viele Anschuldigungen und Erwartungen für das kleine Tool für Aufgaben welche garnicht zu ihm gehören.
Der Arme Dev
Nur bitte ladet Daten hoch.
Das hier ... sind keine Daten
Sie sind nicht brauchbar, außer sich zu beschweren dass es nicht läuft
Wir wissen alle schon dass es bei 95+ % der Leute "einfach so" nicht läuft.
Es ist eine traurige Realität aber so wurde die Hardware verteilt.
Doch keiner von uns bewegt sich dorthin sie sich anzuschauen.
Es ist ungenügend mit memtests kommt man nicht weiter
Es gibt zig programme welche diese Auslastung erzwingen können dass sich als Report dann darstellt
Bloß wo sind diese Reports.
Kein ZenPT log wärend der Error kaam bzw vor.
Kein Verbose logging fenster, was es logt wie viele es logt, welche Sensoren aktiv sind. Video ??
Kein Package Throttle test, obwohl das überhaupt nichts mit WHEA zu tun hat (1CCD max write bandwidth test)
Kein CPU stability test, nur low IPC memtests. Wobei auch voltage instability kaum WHEA's auslöst.
Womit soll ich den bitte arbeiten wenn man nur Luft postet.
Das klingt soo harsh, aber es ist traurig zu lesen "es läuft nicht, ich hör auf"
Wenn man sich nicht mal die Mühe macht diese Requests sich anzuschauen welche mehrmalig geschrieben wurden. 😔
Natürlich dass dann nichts rauskommt.
Aus nichts kommt nichts. Es ist kein mem-stability problem, wobei auch das unklar ist
~ wenn man GDM rennt und FCLK nicht von MCLK:UCLKK trennt. Welches auch als Request gebeten wurde.
Keiner hat sein NIC überprüft
Keiner (zu 98% sicher) hat sich https://www.overclock.net/threads/w...h-fclk-without-performance-penalties.1778781/ angeschaut
WHEA sind größtenteils Boardfokussiert und CPU Substrate fokussiert. Weg von MCLK und manchmal weg von der CPU ~ WHEA #18 gehört dann den Kernen.
Nicht jeder WHEA #19 ist gleich
Solltest du bei Win11 sein, lade ich gerne den Powerplan hoch.
Generell war balanced immer zu empfehlen, da custom PP overboost spikes erstellen.
C-State oder DF state wakeup spikes.
Verpeilt ~ busy
Hier bitte:
~angehängt~ , minimal von mir angepasst
Import:
cmd mit admin rechte
cd C:\Users\USERNAME\Downloads\Ryzen_LP1.4 (zum pfad)
powercfg /IMPORT "C:\Users\USERNAME\Downloads\Ryzen_LP1.4\RyzenLP1.4.pow"
win+r control panel
-
Aktivieren und neustarten ! (Wichtig aufgrund von CPPC)
HWInfo nicht mehr benützen und nur ZenPT + Event Viewer nutzen um logs auszulesen
HWInfo kann eine Race Condition erstellen und somit auch der Grund für Logs sein,
abseits davon dass es nicht alle WHEA's loggt ~ da windows es standartmäßig selbst nicht macht
Beitrag automatisch zusammengeführt:
Wenn man mir dann auch etwas Information über den NIC (Ethernet) gibt, kann man gegenprüfen ob dieser OK ist
Aber ... ich arbeite mit Luft.
Wortwörtlich keine Reports außer Beschwerden dass es nicht läuft~~
Zb:
Ich hab durch d*mmheit und Lernexperimente mein NIC zerschossen.
Das ist das Fenster welches ich brauche ~ neben dem ZenPTMonitor Video bevor und wenn ein Error Spam kommt (mit load, egal welcher Art diese produziert)
Auch ich bedanke mich für alle Tipps bei allen die sich hier engagieren. Und muss auch sagen, dass ich hier nach Pareto-Prinzip arbeite: was ich mit vertretbarem Aufwand erreiche kann, versuche ich. Aber wenn ich hier nun von zwei Personen lese, dass man ein Jahr investiert hat ist mir auch klar, dass ich das nicht zu leisten bereit bin. Seid ihr bereits zu teilen - was ihr ja seid, dann super & danke! Würdet ihr eure Erkenntnisse nicht teilen wollen, dann könnte ichs nicht ändern.
Den Thread vom WHEA Supressor kenne ich von Anfang an, aber hab den dann irgendwann nicht mehr weiter verfolgt, weil ich jetzt lange Zeit einen 5800X hatte, der einfach keine WHEAs produziert hatte, egal was ich eingestellt hab.
Die Diskussion bzgl. Logs werd ich mir da mal ansehen - davon hab ich noch nichts gehört, hab keinerlei Ahnung dazu und muss mich da von 0 beginnend mal auf einen Stand bringen, um zu beurteilen, ob ich mich damit beschäftigen will.
Better EDIT : Long story, short version🔝
Told ya earlier in previous reply, we will never find out just by copying settings, from where are coming Wheas in our individual builds in comparison, but cause we are running different sample X3D in diff. components combo: chipset/mobo/mem/gpu
And for this point, you need to start from ground 0 looking for your issues, as I did, first starting research for wheas free at 3866mhz, with help by @Veii indeed and by continous work researches by AM4 rising early years
Indeed, he encouraged me all the time, to continue when was so closer to give up looking for my goal, which was Gaming IF2000 X3D Wheas free 🙏
Beitrag automatisch zusammengeführt:
Just assuming, as you did for me aren' t wheas free, guess you are looking for Gaming Wheas free, and not only IF2000 top, cause idk which your goal is ?
Better do not spend all your days testing Wheas MemOC topic TM5 at IF2000, try to relax your mem freq and enjoy your games, when you are out of OC ideeas, and reload looking for wheas issues, with Luxxer's help when you have plenty of time, cause my BCLK route for IF2000 was a lot of time consumer for me daily in the latest 3months, and not counting anothers more losted for 3933mhz stable Profile last year🤕
Anhänge
IMG_20240425_111320.png
194,4 KB
· Aufrufe: 34
CP2077_5800X3D_4000CL14_GearON_101.75_PBO 100-70-60_CO-PerCore_LCLK DPM off #.png
interessant , das es nicht nur im Intel RAM OC Thread und im OC Forum solche Probleme mit der Person gibt sondern auch hier - und das er die schuld und falsches verhalten immer auf andere schiebt ...
und 0 Einsicht hat obwohl er sich teilweise falsch verhält.
nur er hat recht -> alle anderen haben unrecht ...
@Tatilica there is a chance that you arent at all
But also a chance that it doesnt matter, as critical reports ≠ instability
All the logs for you report zero, even in verbose.
You need to have reports of #42, per active sensor
And report of #5 on successfull initialization of target sensor.
Those appear every successfull boot.
Both are missing here, soo chance is high that its service and group policy is disabled on win 10
On win 11 such is harder, soo i dont think you are on it.
Suppressor was used to prevent dpc spikes due to error spam
At the time the spam was due to NIC issues and chipset issues in general (600errors/sec) without being a performance penalty
Such is not needed anymore and full stability + log free should be targeted.
// NIC FW reflash may not be needed anymore, but i need to verify myself. No trust, but "should" be resolved by now on last 2-3 AGESA and with latest drivers.
Log free doensnt mean clean log. It means no warnings in there.
Vebose logging remains required, to approve sensors are even active.
You may be at 6/10 sensors, may be at 10/10
But currently its unknown because event-viewer service appears disabled. Or log was cleaned
Sensor active log depends on what FW is on the Chip
(microcode + X, patches over to ARM inside chip, on boot if required)
And what settings Boardpartner configured for corresponding bios defaults.
Any case , no logs there means they are disabled on OS level.
Soo please look for a fix.
, denn (ich glaub ich habe das hier eh auch schon geposted):
