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.
hast du die settings irgendwo kopiert weil so richtig ergibt das für mich alles keinen sinn. ? (ich finde die spannungen zu hoch für das was da an timings und mhz eingestellt hast)
schon mal cl36 mit 8200mhz versucht ? was passiert wenn du vdd und vddq senkst (ich würde es so mit 1.47v/1.45v versuchen) , sa würde ich auch versuchen zu senken da ist oft weniger mehr ((1.2-1.24v)) tx würde ich erstmal auf auto lassen und imc auf 1.4-1.42v einstellen
trefi kannst du deiner kühlung anpassen
bei den timings fang ich zb immer so an :
das ist solide und lief bei mir bis jetzt bei jedem stick sofort - da teste ich erstmal tm5 und karhu , und dann fang ich an zu verfeinern bzw anzupassen.
bei karhu reichen erstmal 5k für den anfang - einfach boxen an und ins wohnzimmer gehen film schauen xD (piept ja dann wenn die 5k erreicht sind oder nen error kommt)
hast du die settings irgendwo kopiert weil so richtig ergibt das für mich alles keinen sinn. ? (ich finde die spannungen zu hoch für das was da an timings und mhz eingestellt hast)
schon mal cl36 mit 8200mhz versucht ? was passiert wenn du vdd und vddq senkst (ich würde es so mit 1.47v/1.45v versuchen) , sa würde ich auch versuchen zu senken da ist oft weniger mehr tx würde ich erstmal auf auto lassen und imc auf 1.4-1.42v einstellen
trefi kannst du deiner kühlung anpassen
bei den timings fang ich zb immer so an :
das ist solide und lief bei mir bis jetzt bei jedem stick sofort - da teste ich erstmal tm5 und karhu , und dann fang ich an zu verfeinern bzw anzupassen.
bei karhu reichen erstmal 5k für den anfang - einfach boxen an und ins wohnzimmer gehen film schauen xD (piept ja dann wenn die 5k erreicht sind oder nen error kommt)
...das sind aber 24Gb Module die er hat, ich meine die gehen nicht so trivial auf Cl 36 ; niedrigere rfc2 / pb erst recht nicht. Ich meine das passt so bei Ihm. Edit vlt tcke rauf und twr noch ein wenig runter, aber bei >3h karhu würde ich mir keine Sorgen machen, es sei denn Y-Cruncher (2.5) schmiert gesichert wegen dem RAM ab.
...das sind aber 24Gb Module die er hat, ich meine die gehen nicht so trivial auf Cl 36 ; niedrigere rfc2 / pb erst recht nicht. Ich meine das passt so bei Ihm.
okay, meine habe ich NIE stable auf Cl36 hinbekommen, was ich auch gemacht habe z.b. 36/50/50 1,55VD / 1,50VDDQ ; SA > 1,26 . nur IMC V größer 1,41x hatte ich nie probiert.
meine 2x 24gb mdies wollte damals keine vdd/vddq über 1.49v xD sobald ich das eingestellt hatte lief genau garnichts straffes mehr vielleicht ist das bei dir auch so ? (das war mega wierd) und sa bug hast du nicht oder ?
meine 2x 24gb mdies wollte damals keine vdd/vddq über 1.49v xD sobald ich das eingestellt hatte lief genau garnichts straffes mehr vielleicht ist das bei dir auch so ?
okay - ich bin immer noch auf der 1701 beta - was mir mächtig auf den Sack geht ist halt die ewige Aktualisierung von Aura RGB über den Bios Flash, das bringt openrgb immer durcheinander...
okay - ich bin immer noch auf der 1701 beta - was mir mächtig auf den Sack geht ist halt die ewige Aktualisierung von Aura RGB über den Bios Flash, das bringt openrgb immer durcheinander...
13900K
Der Jump on Core to roundtrip Thread beträgt ~4ns (min 4, max 4.1)
Der Jump von P-Core zu E-Core ~ avr 15ns delta (min 36.8, max 54.5)
Der Jump von P-Core zu P-Core ~ avg 5ns (min 22.8, max 32.8)
// maximale Werte sind Core - Cache - Core.
7950X :
Core to SMT ~6.3ns (min 6.2 max 6.3)
Core to Core ~16.5ns (min ~15.2ns, max 18.2ns)
CCD to CCD ~ 58.7ns
Core to $ to Core~ 6.2ns
Core to $ same CCD ~ 16ns
Core $ to CCD to $ ~ 130ns
7800X3D
Core to SMT ~8.9ns
Core to Core ~19.4ns
CCD to CCD ~ 19.7ns
Mate, it's 2024;
You know we can measure such stuff, right ? 🤭
Good morniing
Beitrag automatisch zusammengeführt:
@RedF kann noch gerne Core2Core & SiSandra von seinem 7800X3D dalassen.
Ich bin die letzten 30 Seiten im DDR5 Thread & deinem Profil bis Jänner durchgegangen
Ich konnte leider keines deiner Bilder/Tabellen finden
So als ein weiteres Beispiel 🤭
Den mein/clients ehemaliger 7800X3D ist einfach unfair als Vergleich.
EDIT:
Use this if your game/title (for example Fortnite) has trouble with core & cache differentiation https://bitsum.com/apps/coredirector/ forces target application on P-Cores
But likely better for AMD & Intel (from i7-970 to 14th gen) & Athlon to X3D
lol das neue bios hat einfach mein windows komplett gekillt - es ging einfach garnichts mehr musste jetzt windows neu installieren ... und dieses denglish macht mich echt fertig hier ... wieso kann man nicht einfach in einer sprache schreiben (in einem post) und am besten auch so das es jeder versteht ...
"Hyper-Threading (HT) / Simultanes Multithreading (SMT) :
Diese Funktion ermöglicht es dem Betriebssystem, einen physischen Kern als zwei virtuelle Kerne zu betrachten. Diese Funktion ist zwar gut für High-Threaded-Lasten wie Rendering oder Kompilierung, erhöht aber die Latenz des Systems massiv. Dies liegt daran, dass die Kerne nur eine Ausführungseinheit haben, was dadurch verschlimmert wird, dass das Betriebssystem versucht, die Last auf beide virtuellen Prozessoren desselben Kerns zu verteilen, was zu einem Stillstand führt, während die Ausführungseinheit des Kerns mit dem zweiten logischen Prozessor beschäftigt ist."
wenn ich HT deaktiviere senke ich die temperatur meiner cpu um ~15grad , kann dadurch den takt meiner pcores weiter anheben weil ich nicht mehr so schnell ins thermale limit laufe ... klingt doch komplett logisch oder ? , ein game brauch keine 1337 kerne die meisten games benötigen ~6-8kerne und diese am besten mit soviel mhz wie möglich ...
so erreiche ich bei games wo ich ins cpu limit laufe viel viel viel höhere fps ...
und deine core to core latency ist mir eggal , weil es eben um INGAME LATENCY geht !!! ... (bei core2core ist der 7950x zb auch ein schlechtes beispiel der hat ja von haus aus eine hohe latenz weil er halt mehrere ccd's hat)
hast du die settings irgendwo kopiert weil so richtig ergibt das für mich alles keinen sinn. ? (ich finde die spannungen zu hoch für das was da an timings und mhz eingestellt hast)
nein ist nicht kopiert
VDDQTX 1,35 = Auto setting im Bios
IMC 1,4 = Nierdriger nach <10min fehler in Karhu
SA 1,3 = sollte ich mal niedriger testen, richtig
VDDQ 1,46 = (XMP 1,45) höher fehler bei Karhu, niedriger fehler bei TM5 (eventuell änder sich das bei niedrigerer SA)
VDD 1,51 = (XMP 1,45) Niedriger fehler bei Karhu um ~3000-5000%
Sorry aber TM5 nehme ich gar nicht mehr, ich "vertraue" da Karhu & auf jeden Fall Passmarks Memtest 86 pro (ganz wichtig die pro version auch wenns 50+Euronen kostet) - dann noch 2 runden Y-cruncher 2,5 und gut iss.
Sorry aber TM5 nehme ich gar nicht mehr, ich "vertraue" da Karhu & auf jeden Fall Passmarks Memtest 86 pro (ganz wichtig die pro version auch wenns 50+Euronen kostet) - dann noch 2 runden Y-cruncher 2,5 und gut iss.
ich nutz immer eine combi aus karhu/tm5/vst - dann hab ich soweit alles abgedeckt was man grob testen kann (es kommt halt auch immer drauf an was man gerade testen möchte) -> der finale test passiert dann beim gaming.
SA 1,25V ist karhu 10000 gelaufen hatte nimmer daran gedacht da was weg zu nehmen, werd gleich mal noch nach VDD und VDDQ Schauen. CL36 wollte er bei 8200 nimmer, vieleicht wenn weniger VDD/VDDQ, werd ich anschließend testen.
"Hyper-Threading (HT) / Simultanes Multithreading (SMT) :
Diese Funktion ermöglicht es dem Betriebssystem, einen physischen Kern als zwei virtuelle Kerne zu betrachten. Diese Funktion ist zwar gut für High-Threaded-Lasten wie Rendering oder Kompilierung, erhöht aber die Latenz des Systems massiv. Dies liegt daran, dass die Kerne nur eine Ausführungseinheit haben, was dadurch verschlimmert wird, dass das Betriebssystem versucht, die Last auf beide virtuellen Prozessoren desselben Kerns zu verteilen, was zu einem Stillstand führt, während die Ausführungseinheit des Kerns mit dem zweiten logischen Prozessor beschäftigt ist."
Das ist leider nicht der Fall
Der CoreCLK ist quasy unwichtig
Es ist ein summierter Wert (placeholder)
Wie oft der angegebene (virtuelle) Wert , im weiteren Placeholder Wert (mhz/sec) gesendet werden darf.
Zu dieser Rechnung nun gehören, dass die BufferQueue nur so voll werden kann, wie der opcache die jeweiligen Instructionsets (größe und art) , in kleinen Chunks/Happen unterteilt werden können.
Somit bei kleinen FFT "Päckchen" füllt es die Bufferqueue schneller, und somit wird mehr hitze erstellt, da die gesammtlast höher ist.
// sehr simplifiziert
Manche SKUs können zb AVX2 nativ innerhalb eines Cycles bearbeiten
Andere ehmalige zersetzen den AVX256 blob in doppelte AVX128 päckchen und brauchen 2 clockcycles.
Usw und so fort
Im Grundegenommen, bedeutet die Kernfrequenz garnichts.
Was reale Leistung ausmacht, ist die größe der Bufferqueue (backend)
Die effektivität des Branchpredictors & OPCache (wie gut es "loadtypes" erkennen und in kleine Happen zersetzen kann)
Und dann zu welcher Leistung der gesammte Transfer stattfinden kann
QCLK, RINGCLK, FCLK, CoreCLK
Auf diesem dann die effektivität des IVR (MHz) & DVFS design
Sprich innerhalb wie vielen cycles darf es die Spannung regulieren, bis die Kerne nicht mehr die Frequenz halten können und nochmal ein chunk spannung sich nehmen müssen.
Diese effektivität des designs, gibt im Grundegenommen den maximalen Takt des Samples an.
Manche sind leaky manche weniger.
Alles so simplifiziert wie möglich.
Doch eigentlich bei "roher leistung" spielt nur die Cache geschwindigkeit eine Rolle und die interne latenz wie sehr kerne nach derren L1Data, L1Instruction
Zu L2 und dann runter zu dem globalen L3 cache, daten ablagern
Da jeder Kern Zugriff, wie bei der GPU vom VRAM
Muss runter zu dem cache, bevor entschieden wird ob man Daten vom Ram hin-und-her laden muss
Oder es Intern schneller ist mit niedriger Latenz, um Daten hin und her zu tauschen.
Beitrag automatisch zusammengeführt:
Oft braucht es weder eine schnelle abtastrate (niedriger coreclk ist ok), noch spannung oder leistung um das Datenpäckchen zu bearbeiten.
Oft haakt es auch an der Application selbst, welche Art von Daten sie versendet und ob ihr überhaupt bekannt ist wie viele Threads im system sind.
Der application interessiert es nicht wie viele Threads existieren.
Sie muss nur wissen wohin sie es laden soll.
Je nachdem was die CPU dem Betriebssystem mitteilt
Welcher kern weitere commands erwarten kann, und was "noch in stau ist" und gerade bearbeitet wird.
Alles eine kurzfassung.
Am handy schreibt es sich schwer
Beitrag automatisch zusammengeführt:
Mit anderen Worten, stört es nicht ob 2 oder 4 threads pro Kern existieren
Die Bufferqueue ist global
Welche Kerne reinladen, ist unwichtig.
Und nein jeder Kern kann mehr als einen Command bearbeiten : ')
Im Grundegenommen ist es weitaus schneller Daten innerhalb des Virtuellen Kerns zu bearbeiten , damit die Bufferqueue effizienter von "schwachen" Lasten gefült wird.
Als zwischen weit entfernten Kernen zu springen, durch den Cache zu müssen und dann dadurch weitaus mehr Spannung reinladen muss, um mehr als einen Kern zu versorgen.
Da kern lasten nicht linear skallieren und alle derren eigenen Chunk an Spannung brauchen.
1kern 700mV
2 kerne 1400mV
Funktioniert zb nicht als Rechnung
Ebenso ein Märchen
So funktionieren CPU designs nicht
Threads stören nicht. Es gibt nur leicht "suboptimal-designte" Programme, welche hier und da etwas Druck brauchen, daten Inteligent zu verteilen.
Im aktuellen Intel Design,
Ist die Backend groß genug um effizient zu arbeiten und diese zu füllen.
Im zukünftigem Design, wird der HT entfernt und neu-designed.
Das hat mir der aktuellen SKU jedoch nichts zu tun.
Alle CPUs funktionieren perfekt, so wie sie aus Intel-HQ kommen.
Die CPU zu kastrieren, nur weil eine Application abenteuerlich resourcen verteilt ~ ist etwas unlogisch und eine umgehung des eigentlichen Problems.
Ebenso eine verschwendung des Designs und einschränkung potentieller Leistung.
Den zwischen Kernen zu springen ist abseits langsamer, auch stromfressend.
die meisten infos sind zusammengesammelt , habe auch viel von freunden oder selbst getestet. habe auch geräte zum testen wie nvidia reflex analyzer , habe aber auch syslat und osrtt ... (ldat kann ich mir bei einem mate leihen ab und zu)
habe zb beim csgo bench leute "nass gemacht" die deutlich stärkere hardware haben und das locker mit meinem 24/7 setup ohne großes oc ... (ht macht da fast 100fps unterschied)
Die CPU zu kastrieren, nur weil eine Application abenteuerlich resourcen verteilt ~ ist etwas unlogisch und eine umgehung des eigentlichen Problems.
Ebenso eine verschwendung des Designs und einschränkung potentieller Leistung.
du nimmst multicore leistung weg (die du im gaming eh nicht benötigst) und wärme nimmst du auch weg
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt
im fall von csgo waren 100mhz 15-25fps ...
das man die cpu dann nichtmehr inerhalb der spezifikationen betreibt sollte aber klar sein.
- im übrigen rede ich hier von allen spielen die im cpu limit sind , sei es valorant , csgo , cs2 , fortnite , rb6 , apex und und und -
aber egal lass nun gut sein
Ich bin mir nicht sicher ob du Leistung auf MHz beziehst
Und Leistung als fixierten Clock ausmachst.
Ich sehe viel Testing, aber kein Nachgehen des Problems
Der APP und das Betriebssystem
Die CPU arbeitet perfekt, so wie sie aus Intel's lager kommt.
Von Tweakern halte ich nicht viel, tut mir leid.
Die Logik der meisten ist auf positiven Beobachtungen basiert ohne die Tradeoffs zu beachten.
Die Calypso Person wäre mir bekannt.
Sehr viele Leute mit OS Problemen kaamen ehmalig zu mir (momentan den Kumpel welcher als SI tätig ist)
Da diese Leute Registry Sachen empfehlen, welche sich schon im Berreich Snakeoil befinden.
Auf gut deutsch heißt es "verschlimmbessern"
Ein Beispiel davon wäre die Empfehlung die kerne auf konstanter max-last zu halten und C/P states zu deaktivieren
Welches konstant 1.43-1.45v im Idle durchlässt, da man einen Exploit im Powerplan nutzt.
Das Problem hier wäre, dass diese Architektur kaum Clock-gated ~ zumindest nicht im Frontend.
Usw und so fort.
Das Thema mit "BAR off" ist schneller
Ist ein ähnliches. Placeboo, ohne erklärung weswegen Frametime desync zwischen GPU & CPU in X tests bessere peak framerate erzeugt ... und weiteren schmarn. 🤭
Tut mir leid,
Mir alles bekannt.
Ich war in dieser Szene und glücklich einen klaren Kopf gefunden zu haben.
Alles beruht auf vertrauen und "testen".
Nahezu niemand von diesen Tweakern macht sich die mühe derren Änderungen nachzufolgen , geschweige den zu verstehen.
Es wird nur "Daten" auf Abwurfebene gesammelt. "Throw stuff at the wall and see what sticks, not why it does or doesnt".
Ah , muss mich nicht kümmern
Aber ich möchte dir erklären dass du etwas durch viel Tweaking übersiehst.
Und zwar das "Wieso & Warum"
Die CPU beginnt nicht plötzlich intern anders zu arbeiten , nur weil man den Oberflächlichen Teil der Dynamik ruiniert bzw die CPU kastriert.
Ohne diese Fragen,
kann man kaum von Main vs Side-Issue unterscheiden und reitet sich nur weiter rein in diesem Tweakers feld.
Ich hoffe es kommt die Zeit worin auch du diese Empfehlungen hinterfragst. Auf hardware ebene
AMD’s Zen 4 architecture has been hotly anticipated by many in the tech sphere; as a result many rumors were floating around about its performance gains prior to its release. In February 2021…
Please go through part 1 of our Zen 4 coverage, if you haven’t done so already. This article picks up where the previous one left off. To summarize, Zen 4 has made several moves in the fronte…
du nimmst multicore leistung weg (die du im gaming eh nicht benötigst) und wärme nimmst du auch weg
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt
Ob man nun den Zugriff zu den "Cache und E-Cores" abschaltet
Oder intern "die Chance auf effizientem befüllen der BufferQueue" verhindert bzw limitiert. Nun "downgraded"
Ist die reine Definition von "kastrieren", mit der Ausnahme dass man es Rückgängig machen kann.
Eine andere Definition dafür abseits "Verschlimmbessern" wäre, "Downgrading mit situationsbasierten Einzelziffer % Austausch von potentiellem Zugewinn"
Ah beides kommt auf das selbe hinaus.
Sobald man seine Sicht außerhalb des Betriebssystem setzt und erkennt was man der Hardware antut,
Sollte sich zeigen dass man sich in einem Teufelskreis voller selbst-erstellten Problemen befindet.
Beides wäre mit "nein" zu beantworten.
Weder das eine, noch das andere definieren Rohleistung.
CoreClock ist nur einer von mehreren Frontend Clocks.
Er ist sehr unwichtig~
Er war wichtig im Jahre 2015 worin man noch auf Allcore-Clock setzte.
Wobei Intel's DVFS & IVR auch schon damals existierte
Weswegen man auch damals auf fixiertem Clock ging, ist unverständlich.
Womöglich einfach fehlendes Belehren der Community(s) wie deren Hardware funktioniert.
habe zb beim csgo bench leute "nass gemacht" die deutlich stärkere hardware haben und das locker mit meinem 24/7 setup ohne großes oc ...
(ht macht da fast 100fps unterschied)