Mmm,
LLC 7 und TVB 6.3GHz waren fraglich.
Eigentlich sind sie es immer noch.
Hast du den irgend einen Screenshot worin das Setup den läuft ? @AndreasP1981
Karhu ist nicht bekannt als Kern Stabilitätsprogram durchzugehen.
TM5 umso weniger bzw garnicht.
Beide werden durch Kern & Ring Instabilität beeinflusst, aber TM5's Aufgabe ist es , eben so gut es geht nicht beeinflusst zu werden.
Es ist ein low-ipc SSE Load.
Weswegen seine einzige Aufgabe ist, MemTimings Stabilität & stutter-access / stutter-voltage , zu testen.
Zumindest so läuft die 1usmus Config. Die Anta config basiert auf "charge hold" duration
~ welches sich kaum von Karhu (20K) oder HCI/Dangwang (1000%) Unterscheidet.
// Eines der Gründe wieso ich TM5-anta, nun ja, etwas Zwecklos finde ~ wo Karhu & HCI bzw Stressapptest & GSAT (linux) doch einen weitaus besseren Job für dieses Ziel machen.
All das ist der Grund weswegen man mehrere tests durchlaufen lassen muss.
Jedes für seinen Zweck.
Und weswegen es gut ist dass man mindestens 3-4 cycles y-cruncher durchbekommt, bevor man memory stresstests startet, oder sein system als "stabil" betitelt.
^ Eventuell wäre OCCT Extreme Large Dataset, eine alternative (dauert aber 60min)
TM5 stabil heißt nur, dass bei schwacher Last und bei idle last - der Zugriff zum Ram & innerhalb des RAMs "ok" sind.
Das ist sehr weit weg von "stabil". Nur dass das MemPCB & die MemTimings ✅ sind. Mehr nicht;
Bei Karhu wäre das das selbe bloß mit "Ring & Mem" sind einigermaßen ok. Bedeutet jedoch ebenfalls nicht dass die CPU "stabil" ist.
Der Supply zu den E-cores und Ring ebenso, jedoch sind E-Cores+Ring & P-Cores getrennt.
Nur der IVR & FIVR ist hier die Variable zwischen dem Supply beider.
Es spricht sich herum dass E-Cores Einfluss auf dem IMC hätten,
Aber es ist eher anders rum.
Ring kann Instabilität verursachen, worin es nichts mit dem IMC (QCLK) zu tun hatte.
Der IA/SVID "default" supply, unterscheidet sich zwischen Boardpartnern, Chipsets und zwischen Biosen.
Man sollte diesen jedoch nicht übersehen bzw ignorieren. Besonders nicht wenn man mit Telemetry-Faking rumspielt (IA_AC_LL)
EDIT:
Was ehemalig VDDCR_IA & VDDCR_SA hieß
Ist mittlerweile automatisiert und von DVFS+(F)IVR abhängig (das load-balanced Päckchen)
Man kann zwar VDDCR_SA (wobei unser SA auch eher eine VID ist) direkt beeinflussen, VDDCR_IA jedoch nicht.
Was für den IMC übrig bleibt, hängt von den Kernen und dem Ring ab. // EDIT: VCCDDR ist automatisiert.
Alles ist loadbalanced und basiert auf VIDs. Nun "Margins/Spielraum" halt.
Wenn man sich dann genauer das PL4 limit anschaut,
Sollte einem auch auffallen dass DDR Supply mit drinnen hängt.
Natürlich, den alles ist Load balanced. 🤭
LLC 7 und TVB 6.3GHz waren fraglich.
Eigentlich sind sie es immer noch.
Hast du den irgend einen Screenshot worin das Setup den läuft ? @AndreasP1981
Karhu ist nicht bekannt als Kern Stabilitätsprogram durchzugehen.
TM5 umso weniger bzw garnicht.
Beide werden durch Kern & Ring Instabilität beeinflusst, aber TM5's Aufgabe ist es , eben so gut es geht nicht beeinflusst zu werden.
Es ist ein low-ipc SSE Load.
Weswegen seine einzige Aufgabe ist, MemTimings Stabilität & stutter-access / stutter-voltage , zu testen.
Zumindest so läuft die 1usmus Config. Die Anta config basiert auf "charge hold" duration
~ welches sich kaum von Karhu (20K) oder HCI/Dangwang (1000%) Unterscheidet.
// Eines der Gründe wieso ich TM5-anta, nun ja, etwas Zwecklos finde ~ wo Karhu & HCI bzw Stressapptest & GSAT (linux) doch einen weitaus besseren Job für dieses Ziel machen.
All das ist der Grund weswegen man mehrere tests durchlaufen lassen muss.
Jedes für seinen Zweck.
Und weswegen es gut ist dass man mindestens 3-4 cycles y-cruncher durchbekommt, bevor man memory stresstests startet, oder sein system als "stabil" betitelt.
^ Eventuell wäre OCCT Extreme Large Dataset, eine alternative (dauert aber 60min)
TM5 stabil heißt nur, dass bei schwacher Last und bei idle last - der Zugriff zum Ram & innerhalb des RAMs "ok" sind.
Das ist sehr weit weg von "stabil". Nur dass das MemPCB & die MemTimings ✅ sind. Mehr nicht;
Bei Karhu wäre das das selbe bloß mit "Ring & Mem" sind einigermaßen ok. Bedeutet jedoch ebenfalls nicht dass die CPU "stabil" ist.
Beitrag automatisch zusammengeführt:
Der IA supply zu den P-Cores, sowie der Supply zu dem IMC ~ kommen von der selben Quelle.
Der Supply zu den E-cores und Ring ebenso, jedoch sind E-Cores+Ring & P-Cores getrennt.
Nur der IVR & FIVR ist hier die Variable zwischen dem Supply beider.
Es spricht sich herum dass E-Cores Einfluss auf dem IMC hätten,
Aber es ist eher anders rum.
Ring kann Instabilität verursachen, worin es nichts mit dem IMC (QCLK) zu tun hatte.
Der IA/SVID "default" supply, unterscheidet sich zwischen Boardpartnern, Chipsets und zwischen Biosen.
Man sollte diesen jedoch nicht übersehen bzw ignorieren. Besonders nicht wenn man mit Telemetry-Faking rumspielt (IA_AC_LL)
EDIT:
Was ehemalig VDDCR_IA & VDDCR_SA hieß
Ist mittlerweile automatisiert und von DVFS+(F)IVR abhängig (das load-balanced Päckchen)
Man kann zwar VDDCR_SA (wobei unser SA auch eher eine VID ist) direkt beeinflussen, VDDCR_IA jedoch nicht.
Was für den IMC übrig bleibt, hängt von den Kernen und dem Ring ab. // EDIT: VCCDDR ist automatisiert.
Alles ist loadbalanced und basiert auf VIDs. Nun "Margins/Spielraum" halt.
Wenn man sich dann genauer das PL4 limit anschaut,
Sollte einem auch auffallen dass DDR Supply mit drinnen hängt.
Natürlich, den alles ist Load balanced. 🤭
Zuletzt bearbeitet:
