[Sammelthread] Intel DDR5 RAM OC Thread

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
VDD 1,51 VDDQ 1,46 SA 1,3 IMC 1,4 VDDQTX 1,35

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 :

ybfNwTK.png

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)

vgthX2h.png
 
Zuletzt bearbeitet:
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 :

ybfNwTK.png

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)

vgthX2h.png
...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.
 
Zuletzt bearbeitet:
...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.

doch doch geht genauso gut , ich finde sogar das sie besser gehen weil mdies der 2ten generation (hatte ich auch schon)

rfc kann man anpassen aber das was er da eingestellt hat ist deutlich zu hoch für meinen geschmack vorallem für ein KS + ENCORE

und was mir auch sofort aufgefallen ist - er hat halt wirklich noch den HT kram an ... und das für ein "gaming rig" ...
 
Zuletzt bearbeitet:
doch doch geht genauso gut , ich finde sogar das sie besser gehen weil mdies der 2ten generation (hatte ich auch schon)

rfc kann man anpassen aber das was er da eingestellt hat ist deutlich zu hoch für meinen geschmack vorallem für ein KS + ENCORE
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 ?
...kann ich gerne mal probieren- welche XMP spannung hatten deine 24er denn, meine 1,35.
 
xmp 1.35v

ich teste gerade das neue vanilla bios , das bringt mich zum verzweifeln damit läuft nicht mal xmp ... einfach direkt bsod ... lol
 
Zuletzt bearbeitet:
xmp 1.35v

ich teste gerade das neue vanilla bios , das bringt mich zum verzweifeln damit läuft nicht mal xmp ... einfach direkt bsod ... lol...
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...

ja das war glaube auch gut (ich blick schon nicht mehr durch bei den ganzen versionen)

rgb probleme habe ich keine , einmal ausgestellt und seitdem alles aus.

was die neue version gut kann ist niedrige latanzen zieh dir das mal rein :

0s8zhHX.png

macht der einfach so , easy ... ohne mucken zu machen
 
und was mir auch sofort aufgefallen ist - er hat halt wirklich noch den HT kram an ... und das für ein "gaming rig" ...
Selbstverständlich.
für gaming sollte man aufjedenfall auch ht deaktivieren
und latenzen und kann den takt der pcores noch weiter erhöhen.
Nein

E-Cores + Ring ≠ P-Cores supply
Sind weit weg. Unterschiedlicher DVFS+IVR.
dadurch wird ein 14900k schneller als jede amd x3d cpu (+ ddr5 oc) bei gleichzeitig viel viel viel niedrigerer latenz
Und nochmals nein :)
brave_7QhYiO4yAp.png
brave_ibp19FQvTJ.png

^ credits Dr. Ian Cutress
brave_dg9iBhYrbJ.png

^ credits Gavin Bonshor

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.

Sorry but absolutely no : ')
1711352251558.png

1711352315880.png

^ credits Ryan Smith & Gavin Bonshor
1711353609433.png
1711353993505.png

^ credits @Wolf87 ~ #2.352

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
1711353015217.png
1711353171838.png

brave_eaXnsTjOtk.png


Mate, it's 2024;
You know we can measure such stuff, right ? 🤭
Good morniing :wink:
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
 
Zuletzt bearbeitet:
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)
 
Zuletzt bearbeitet:
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.
 
wo bekommt man die? Task Scope ist da ein schickes feature
 
Zip-Datei lässt sich zumindest bei mir nicht öffnen.

Edit: Winrar geht.
 
Siehe Edit - mit Winrar ging auch die andere.
 
kgui graphical user interface.
 
sa würde ich auch versuchen zu senken da ist oft weniger mehr ((1.2-1.24v))
SA 1,25V ist karhu 10000 gelaufen (y) 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.
 
super! , einfach dran bleiben die richtige kombi zu finden dauert anfangs recht lang , aber man wird auch belohnt.
 
"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."
Woher kommt das Zitat
Es fehlt soo viel an Daten.

Ich mein falsch ist es nicht
Aber wirklich Richtig ebenso nicht.

"Ausführungseinheit"
Die Bufferqueue ist riesig.
Und coreclock heißt im Grundegenommen garnichts.
Load balanced.
und diese am besten mit soviel mhz wie möglich ...
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

Auch nicht,
1 kern 800mV
2 kerne 900mV
3 kerne 1000mV

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. :d

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.
 
Zuletzt bearbeitet:
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)

csgo bench:

wQbTwNK.png


ich habe auch andere spiele getestet bei denen das thema HT an oder aus existiert ... und gewaltig einen unterschied macht.

gute infos findet man zb bei "Calypto's Latency Guide" oder von Amit (der hat den csgo autobench programiert)

generell teste ich viel selbst (veröffentliche halt nur nicht viel)

ein beispiel...

reBAR_fps.png


oder cs2 mit ecores an/aus (13900k alles stock) -> sowas testet halt normalerweise keiner

APS1HEQ.png


achja und core2core hab ich auch schon paar mal getestet aber ich find die ergebnisse nicht mehr - das war damals zum release vom 13900k ca.

getestet hatte ich mit MicroBenchX das ist von der capframex jungs.


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.

man kastriert sie im grunde ja nicht wirklich,

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
 
Zuletzt bearbeitet:
und gibst die leistung deinen pcores die höher takten können weil die cpu overall kühler bleibt
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 :geek:

Die beiden Seiten wären sehr empfehlenswert :giggle:
Beitrag automatisch zusammengeführt:

die im cpu limit sind
aber egal lass nun gut sein
Was bedeutet das "CPU limit" ? :)
Was limitiert den innerhalb der CPU & wie kann es Intel/AMD besser machen ?
Beitrag automatisch zusammengeführt:

man kastriert sie im grunde ja nicht wirklich,

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.
Ich bin mir nicht sicher ob du Leistung auf MHz beziehst
Und Leistung als fixierten Clock ausmachst.
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 :coffee3:
Weswegen man auch damals auf fixiertem Clock ging, ist unverständlich.
Womöglich einfach fehlendes Belehren der Community(s) wie deren Hardware funktioniert.
Beitrag automatisch zusammengeführt:

steamwebhelper_DdlKmrBIeQ.png
brave_u9AsdMaDTg.png

65GB ~ do i really want to bother
Ugh, rather not. You can stay #1.
Better for ego 🤭 maybe suboptimal for future, but oh well~
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)
1711381949444.png
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh