[Sammelthread] Intel DDR4 RAM OC Thread + Guides und Tipps

Alles getestet, 3.10, 3.11, auch die Version ohne GUI. Latenz bleibt hier mit MLC höher als mit AIDA, no matter what. Obwohl's am Anfang umgekehrt war, so wie bei dir.

Links AtlasOS10-RAM (schlank), rechts Win 11 Game (heavy loaded). Jeweils 4300-16. Schräg. 🤷‍♂️

4300-16_TM5-stabil+Benches.PNG 4300-16_Win11_Benches.PNG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Diese ganzen Custom-Betriebssysteme wie ReviOS, AtlasOS usw. sind nicht mehr so gut wie sie es einmal waren. Ich habe hier noch eine uralte ReviOS-Version (>2 Jahre), die echt super ist, aber eben auch sehr alt.
 
Versteh auch Leute mit nem Bench OS nicht :d
 
Damals konnte man noch messbare Unterschiede feststellen. Vielleicht ist aber auch einfach Windows besser geworden.
 
@ShirKhan momentan, jetzt, grad angekommen daheim nach weihnachtsfeier, würd ich das gern auf morgen verschieben :d vllt. bekomm ich's gleich in der früh hin, im bus ist gut zeit zB; sonst spätestens am abend dann :gähn:
 
Sehr gern, keine Eile. Lieber in Ruhe und dafür ausführlich. :)
 
aaalso... :d

- alle _MR werte habe ich bei mir deshalb auf den selben wert gesetzt, da ich denke, dass das RAM interne handling (wofür diese timings scheinbar stehen laut UEFI beschreibung; ich kannte diese unterteilung vorher gar nicht, hatte immer nur einen einzigen wert in anderen UEFIs wie zB beim gigabyte board) doch eigtl. flotter sein müsste als die kommunikation zu einem anderen riegel. ob die überhaupt eine auswirkung haben, habe ich allerdings nicht getestet. i did "set and forget" :)

- tCKE: ein mysterium... die einen sagen dies, die anderen das, aber: es scheint aber wohl tats. mit dem RAM powerdown mode zusammenzuhängen ("nix gwiß woaß ma do ned so recht"...), der bei mir eh ausgeschaltet ist. demzurfolge sollte dieses timing eigtl. keine auswirkungen haben: "set and forget" :d bei dir ist das bemerkbar, wenn du den Wert änderst? vllt. hat das auch mit den tert. zu tun, die bei mir ja tats. lockerer sind (die werd ich am Wochenende mal straffen hrhr). da weiss halt wirklich keiner was ganz genaues...

-fixed modes: nachdem alles eingestellt wurde und durch's training und durch die tests kam, wurden div. settings hier danach dann einfach "fixed" = festgesetzt, dass sie so auch bleiben und nicht im auto modus ggf. durch irgendwelche launen des boards doch wieder automatisch neu gesetzt werden (auch schon passiert; mit fixed dann nicht mehr)...

- die tertiären (turn around timings?) haben zwar durchaus auswirkungen gezeigt bei tests, allerdings im Vergleich zu anderen timings so minimal, dass ich mir gedacht habe "fokussier dich auf die anderen, setz die so, dass sie garantiert nicht stören"... die unterschiedlich gesetzten RDWR werte wurden durch mehrere trainings durch das board ebenfalls "schief gesetzt" = unterschiedlich eingestellt; das habe ich dann einfach mal so übernommen (y)

- dynamic mode: fixed übersteht ein training, ohne dass sich etwas ändert, egal was man einträgt; dynamic lässt änderungen durch training dann zu. bei den RTLs hab ich zuerst auto training laufen lassen, was dann zB in 74 - 82 resultierte. als grundwert hab ich dann etwas ca. in der Mitte & relaxteres genommen, was auf jeden fall durchtrainiert werden kann. setze ich das auf 71 zB, oder gar 69, kann es beim training schon zu fehlern kommen ("OC failed, press f1 for UEFI" meldung nach reboot). wenn man dynamic eingestellt hat, braucht man dann bei erfolgreichem training nur noch memory fast boot auf no training stellen, damit diese settings auch so bleiben. die RTLs sind immer noch ein kleines Mysterium für mich: die trainieren sich irgendwie nur bei extrem setups (hoher takt oder straffe timings) alle gleich, sonst immer auf unterschiedliche werte a la 73 / 75. meist lässt sich ein Wert der zwei pro bank / Riegel dann noch anpassen und umtrainieren, der zweite dann aber nicht mehr... ist mir mittlerweile auch egal, ob es gleichmäßig ist oder unterschiedlich ;) solange keine zu große Differenz dort klafft...

okay, rechtschreibfehler bitte ignorieren, der Bus war ganz schön voll lol... der post zeigt freilich nur meine Erfahrungen, die nicht unbedingt allesamt richtig sein müssen; ich denk aber schon, hoffentlich :d

guten Start in den Tag und frohes schaffen!
 
Danke fürs Teilen von Erfahrungen und Einsichten.

mit dem RAM powerdown mode zusammenzuhängen [...] der bei mir eh ausgeschaltet ist

Wo findet man diese Einstellung?

- dynamic mode: fixed übersteht ein training, ohne dass sich etwas ändert, egal was man einträgt; dynamic lässt änderungen durch training dann zu. bei den RTLs hab ich zuerst auto training laufen lassen, was dann zB in 74 - 82 resultierte. als grundwert hab ich dann etwas ca. in der Mitte & relaxteres genommen, was auf jeden fall durchtrainiert werden kann. setze ich das auf 71 zB, oder gar 69, kann es beim training schon zu fehlern kommen ("OC failed, press f1 for UEFI" meldung nach reboot).

Init-Werte auf 77 scheint die RTLs tatsächlich zu fixieren, auf einheitlich 75 hier, was für 4300 angemessen erscheint.

MSI_SnapShot.png

(Kaum geschrieben, habe ich die Inits testweise wieder auf 75/75 gedrückt, erhielt keinen Post und brauchte zwanzig Minuten Reboots, bevor die RTLs wieder auf 4 x 75 waren. :fresse: So einfach ist es also doch nicht.)

wenn man dynamic eingestellt hat, braucht man dann bei erfolgreichem training nur noch memory fast boot auf no training stellen, damit diese settings auch so bleiben.

Das Latency Setting auf "Dynamic" einzustellen hat mit den Memory-Training-Settings zu tun? Das ist hier nämlich der Knackpunkt bei Frequenzen ab 4266 aufwärts. Nicht Stabilität, nicht Fehlerfreiheit in Tests, sondern: boot or no boot? "Fast Boot Enabled" erhöht die Erfolgsquote drastisch, auch während eingestellt und ausprobiert wird (mit Ausnahme der Timings selbst. Die werden hier nur mit vollem Training geändert). "No Training" hab ich bisher als üblen Hack empfunden, den man nach einem singulären erfolgreichen Postversuch anwendet, um ein ansonsten nicht durchgängig bootfähiges Setting zum Starten zu zwingen. Du hast das fest eingestellt? Ich dann jetzt auch wieder. :)

-fixed modes: nachdem alles eingestellt wurde und durch's training und durch die tests kam, wurden div. settings hier danach dann einfach "fixed" = festgesetzt, dass sie so auch bleiben und nicht im auto modus ggf. durch irgendwelche launen des boards doch wieder automatisch neu gesetzt werden (auch schon passiert; mit fixed dann nicht mehr)...

Bei den Tertiären sollte das eigentlich nicht passieren. Mir ist aufgefallen, dass du die sekundären tWTR_S und _L fixiert hast; eigentlich sollten die auf "Auto" bleiben, weil sie durch tWRRD_sg und _dg eingestellt werden. Die können tWTR_S und _L überschreiben, und im ASR TC erscheinen dann andere als die eingestellten Werte. Vielleicht waren das die "Eigenmächtigkeiten", die du festgestellt hast?

Was hast du in "Advanced DRAM Configuration" gesetzt? Irgendwas zusätzlich zu Round Trip = Enabled?

MSI_SnapShot_00.png

Zeig doch gelegentlich mal noch den ASR Timing Configurator und vielleicht Benchmarks, dann wird das Bild vollständig. :) Was mich noch interessiert: Was sagt bei dir die Latenz MLC vs. AIDA? Falls du letzteres installiert hast.

Latenzvergleich_4300_MLC-AIDA.PNG

Ich hab jetzt mehr oder weniger alles so wie bei dir eingestellt (bis auf meine Timings, die bleiben erst mal mit Ausnahme von tREFI, danke für den Tipp) und beobachte das in der nächsten Zeit. Insgesamt scheint das neue Board gleichen Modells (musste das gebraucht Gekaufte nach einem Defekt Ende September ersetzen), einen Tick williger zu sein als das Alte. Mal sehen, ob die 4300-16 bleiben dürfen, fingers crossed. 🤞 Die haben nämlich, siehe hier, den klar höchsten Durchsatz und nur minimal höhere Latenz als 4200-15.

Edit:
Ach, eine Sache noch. Wie stellst du 1,55 V DRAM ein? Mein UEFI akzeptiert dort nur 10-mV-Schritte.
 
Zuletzt bearbeitet:
die Training Einstellungen kann ich heut Abend noch posten, hab auch davon beim bios update Screenshots erstellt. gibt heut Abend dann noch update! :wink: (sowas von keine Lust auf Arbeit heut grmpf...)
 
Also, testseitig ist alles in trockenen Tüchern für meine Ansprüche.

RAM-Test5000_4300-16.PNG 4300-16_GSat_TM5_stabil.PNG

Supergern würd ich zumindest ein Mal mit 4400 auf den Desktop kommen, Timings egal. 😅 Kein Post bei den bisherigen halbherzigen Versuchen. @Phoenix2000: ein Tipp für mich?

Edit:
Argh, tREFI 32 oder 65k macht aber schon einen Unterschied. Glaube, ich bin noch nicht fertig mit testen. :cool:

4300-16_tREFI65535.PNG
 
Zuletzt bearbeitet:
Also, testseitig ist alles in trockenen Tüchern für meine Ansprüche.

Anhang anzeigen 949192 Anhang anzeigen 949193

Supergern würd ich zumindest ein Mal mit 4400 auf den Desktop kommen, Timings egal. 😅 Kein Post bei den bisherigen halbherzigen Versuchen. @Phoenix2000: ein Tipp für mich?
Also ich hatte ja nen Edge Z790 da und 4400 ging da im schnelltest, ich hatte deine Timings aber mit 12/12/12/12. TX 1.41, SA 1.36, VDimm 1.55V.
Wenn der IMC am Limit ist brauch es halt viel SA sprich 1,4-1,43V musst du da schon rechnen. Generell kann ich dir sagen das ich auf dem MSI keine harten Timings wie auf dem Asus gepackt hab und
4500 ist zu grenzwertig, das packt er bei den 2 versuchen nicht^^

Auf dem Asus brauch ich 1.43V rum SA bei 4500 und dann muss ich auch die Timings entspannen damit es bei Memtest läuft, wobei ich das nicht lang daddeln lass wegen der hohen SA, was es auch sinnlos macht.
Sprich rein vom Takt her wo es sinnvoll ist geht auf beiden Boards das gleiche, Timings Asus besser sofern es das Kit kann. VRM hämgt vom Board ab mein erstes Z790 war ne so prall,
das zweite ist um längen besser, packt auch 700khz mit niedriger VCore stable.
Als Vergleich Takt @ Stock mit -Offset MSI bei Vmin 1,148V kackt noch ab, das erste Asus ist da schon stabiler bei 1,148V aber auch ne ganz und das neue eingestellt packt das bei 1,128V.
Ich denke aber das MSI hat etwas mehr VCore angezeigt, vielleicht 1 Step als das Asus... wenn ich nach der Temp gehe wäre das definitiv weniger und das VRM war halt Auto beim Test.

Hab da auch nicht soviel Zeit verschwendet da es vom RamOC/Timings schlechter war, ich hab die ganze Aktion wegen dem VRM gemacht, mir kam das komisch vor das ich soviel mehr VCore brauch bis stable.
Das 2. Asus ist da wirklich besser, schafft auch bessere VMin und bleibt dabei besser stable.

Das er 1,154V andippt war vorher never drin.
1.jpg
 
Zuletzt bearbeitet:
Danke fürs Teilen von Erfahrungen und Einsichten.
(y) ich lern hier auch grad wieder bissl, also ebenfalls danke :d auch an phoenix zB, und the_professor, und viele andere :)
Wo findet man diese Einstellung?
in den memory timings gaaaanz unten: powerdown enable heißt sie glaube ich.
Init-Werte auf 77 scheint die RTLs tatsächlich zu fixieren, auf einheitlich 75 hier, was für 4300 angemessen erscheint.

Anhang anzeigen 949020

(Kaum geschrieben, habe ich die Inits testweise wieder auf 75/75 gedrückt, erhielt keinen Post und brauchte zwanzig Minuten Reboots, bevor die RTLs wieder auf 4 x 75 waren. :fresse: So einfach ist es also doch nicht.)
die RTLs sind halt echt einfach nur ... mindestens tricky, mit tendenz zum nervigen... hab da auch viel gesucht, wie man am besten "even RTLs" bekommt (also alle vier gleich), aber irgendwie hat das alles nicht so richtig funktioniert. teilweise funktioniert nachtrainieren, hauptsächlich jedoch ändert sich im nachhinein kaum noch etwas und sie bleiben festgetackert auf ihren (für mich "falschen", nur weil nicht alle gleich sind) werten. drum ist's mir mittlerweile auch fast schnuppi, ob es 73 / 75 antrainiert, solange es eben nicht zu weit auseinander geht. aber: 4300 landet bei mir auf 73, da musst du wohl nochmal ran :d
Das Latency Setting auf "Dynamic" einzustellen hat mit den Memory-Training-Settings zu tun? Das ist hier nämlich der Knackpunkt bei Frequenzen ab 4266 aufwärts. Nicht Stabilität, nicht Fehlerfreiheit in Tests, sondern: boot or no boot? "Fast Boot Enabled" erhöht die Erfolgsquote drastisch, auch während eingestellt und ausprobiert wird (mit Ausnahme der Timings selbst. Die werden hier nur mit vollem Training geändert). "No Training" hab ich bisher als üblen Hack empfunden, den man nach einem singulären erfolgreichen Postversuch anwendet, um ein ansonsten nicht durchgängig bootfähiges Setting zum Starten zu zwingen. Du hast das fest eingestellt? Ich dann jetzt auch wieder. :)
jop, sobald alles stable ist, kommt das dann auf fixed. ob die werte so bleiben, teste ich nur kurz mit zwei einfachen reboot to UEFI. entweder ist's stable und bleibt so, oder es gibt änderungen und muss weiter trainiert werden.
was auch noch gut helfen soll, angeblich (habe ich pers. noch nicht getestet): zuerst memory try it mit der gewünschten frequenz und anschließend finetuning. das soll angebl. die memory trainings anders stattfinden lassen oder ähnliches, so ganz habe ich das auch noch nicht verstanden (und deshalb auch noch nicht getestet).
Bei den Tertiären sollte das eigentlich nicht passieren. Mir ist aufgefallen, dass du die sekundären tWTR_S und _L fixiert hast; eigentlich sollten die auf "Auto" bleiben, weil sie durch tWRRD_sg und _dg eingestellt werden. Die können tWTR_S und _L überschreiben, und im ASR TC erscheinen dann andere als die eingestellten Werte. Vielleicht waren das die "Eigenmächtigkeiten", die du festgestellt hast?
interessant! ich war bisher der meinung, dass tWRRDSG / DG durch tCL / tCWL und ein weiteres timing (mist... fällt mir grad nicht ein... wird nachgetragen! aber vllt. war es ja sogar das und mir fällt es wieder mal nur ned ein... habe eine angeborene konzentrationsschwäche ;)) beeinflusst / bestimmt wird. das muss ich mir auf jeden fall nochmal genauer ansehen, thx for hint (y)
(hab auf die schnelle das hier dazu gefunden; danke!)
Was hast du in "Advanced DRAM Configuration" gesetzt? Irgendwas zusätzlich zu Round Trip = Enabled?

Anhang anzeigen 949037
training.jpgtraining_00.jpg
vieles hiervon was enabled wurde ist wahrscheinlich nichtmal nötig. hintergrund für dieses trainings-setup war eine testsession, welches training einen boot verhindert und welche einstellungen mit so ziemlich jedem setup ein training schaffen. was wohl reichen soll und schon sehr gut hilft (kann ich durch testen eigtl. auch bestätigen), sind
- round trip latency
- late command training
- rank margin tool
- cmd ctl drive strength / tx equ
alles rein in bezug auf die RTLs.
Zeig doch gelegentlich mal noch den ASR Timing Configurator und vielleicht Benchmarks, dann wird das Bild vollständig. :) Was mich noch interessiert: Was sagt bei dir die Latenz MLC vs. AIDA? Falls du letzteres installiert hast.

Anhang anzeigen 949039
den installiere ich gleich mal noch im zweiten windoze; entsprechende screens reiche ich noch nach :)
Ich hab jetzt mehr oder weniger alles so wie bei dir eingestellt (bis auf meine Timings, die bleiben erst mal mit Ausnahme von tREFI, danke für den Tipp) und beobachte das in der nächsten Zeit. Insgesamt scheint das neue Board gleichen Modells (musste das gebraucht Gekaufte nach einem Defekt Ende September ersetzen), einen Tick williger zu sein als das Alte. Mal sehen, ob die 4300-16 bleiben dürfen, fingers crossed. 🤞 Die haben nämlich, siehe hier, den klar höchsten Durchsatz und nur minimal höhere Latenz als 4200-15.

Edit:
Ach, eine Sache noch. Wie stellst du 1,55 V DRAM ein? Mein UEFI akzeptiert dort nur 10-mV-Schritte.
1.55 sind ja ohne probleme mit den 10mV schritten einstellbar :d meinst du vllt. 1.525 o.ä.? das geht hier ja tats. nicht, beim gigabyte board funktionierte das. 10er schrittchen reichen aber eigtl. ja auch absolut.

so, mal noch ein wenig testen und einstellen, weiter tunen :d
 
Screenshot 2023-12-16 110403.png

joa, älter werden ist nicht unterstützend bei sowas :fresse2:
bzgl. tWRRDSG / DG: an die bin ich tats. anders herangegangen :eek: sobald ich TCL oder tcwl geändert habe, habe ich die beiden auf auto gestellt; diese wurden dann um das was bei tc(w)l geändert wurde auto-angepasst. das war dann irgendwie wohl eher falsch und hat vllt. in Verbindung mit (ggf. dann auch falsch) fixierten twtr_s/_l sogar für unnötigen stress (und eben insg. nicht aufeinander abgestimmte timings?) gesorgt...

wie genau sollt ich in Bezug auf diese nun vorgehen, bin grad verwirrt :confused:
 
wie genau sollt ich in Bezug auf diese nun vorgehen, bin grad verwirrt :confused:

tWTR und tWTR_L auf Auto lassen und über tWRRD_sg und _dg nach dieser Regel einstellen:

Code:
tWTR_S=tWRRD_dg-tCWL-6
tWTR_L=tWRRD_sg-tCWL-6

Gesondert zu tCL und tCWL kenne ich u. a. diese Regeln:

Code:
tRAS=tCL+tRCD+2
tWR=tWRPRE-tCWL-4

Glaube aber, die werden hier nicht besonders ernst genommen. 😅
 
damit überprüfe ich dann gleich mal noch, nachher nach dem Test, das neue 4300 cl15 setting :love: sieht brauchbar aus bisher @1.6vDIMM.
vllt. merkt man, dass ich ein Fan des "set and forget" bin...? :d Stufen sind da meist bei 0.05V Schritten beim RAM, bis max. selbstgesetzte Grenze 1.65V (für die Samsung b-dies). für andere Spannungen 0.025, ggf. später noch anpassen, meist bleibt's aber einfach so :bigok:
 
zwischenstand:
Screenshot 2023-12-16 134259.png

zu beginn zum ausloten der SA und VDDQ-TX startet hier ein custom y-cruncher loop, auf die scheinbar wichtigsten 4x2 iterations begrenzt. das hatte ich im overclock.net forum mal aufgeschnappt, hat sich ganz gut bewährt :) anschl. 5 rounds tm5 anta777 absolut und dann reicht es mir in der regel eigtl. als stabilitätstest, manchmal noch 33.333% karhu test :d

Screenshot 2023-12-12 190541.png

abschließend dann erstmal gaming compiling rendering wie gehabt, einfach weiter nutzen die kiste und wenn es auffälligkeiten gibt, nochmal näher ansehen.
 

Ich finde einfach keinen fu**ing Grund, warum die MLC-Latenz hier immer angeblich 51–52 ns ist. Alles versucht, auf vier(!) OS, Version 3.10 und 3.11, auch neu runtergeladen und entpackt, mit und ohne GUI, verschiedene Installationsorte ... Mir fällt keine Problemquelle mehr ein, die ich noch ausschließen könnte. Nur ganz am Anfang war's ok, nämlich niedriger als bei AIDA. Macht mich narrisch! :-[
 
@ShirKhan
gestern auf 23h2 geupdate, +9ns.

1702736290907.png
 
Zuletzt bearbeitet:
Ahaa! :banana:Danke dir. Ein "Qualitäts"-Update vermutlich, das auf Win 10 und 11 aufgespielt wurde. Dann muss ich mir keine weiteren Gedanken machen, sondern höchstens MLC-Updates beobachten. Sehr schön, you made my day! 👍
 
Kein ding.
Aber Vanguard hat seit dem Update auch kein Bock mehr auf MLC. :fresse:

1702738858077.png
 
höchstens MLC-Updates beobachten

... bzw. Windows-Updates abwarten, wenn MS es verbockt hat und AIDA das nur nicht merkt. Wie auch immer, Vertrauen in die Benchmark-Softwares weckt so was nicht. Aber solange es für alle gleich ist ...
 
Zuletzt bearbeitet:
- late command training
- rank margin tool
- cmd ctl drive strength / tx equ
Hab ich jetzt auch alles enabled. Und RAM-Training danach trotzdem abgeschaltet. Der Kram wirkt nämlich nicht. :ROFLMAO:

4300 landet bei mir auf 73, da musst du wohl nochmal ran
:d
Für 73 brauche ich 4300-15-15. Das hat auch in Windows gebootet (im Gegensatz zu 4400-16) und mir dort sofort das System zerschossen. :LOL:(@Simply1337: Auch deswegen hab ich Bench-Partitionen.)

Ich denke, ich hör erst mal wieder auf. 4300-16 ist mittlerweile auch mit tREFI 65.535 stabil (1,560/1,315/1,405), AIDA hat bei Read und Copy eine Sieben vorn und Latenz <45. Das ist alles sehr erfreulich, mehr als erwartet.

das neue 4300 cl15 setting
:love:
... zwickt mich erst dann, wenn du damit höhere AIDA-Werte zeigst als meine aktuellen. :)

4300-16_tREFI65535_GSat-stabil.PNG 4300-16_tREFI65535_TM5-stabil.PNG 4300-16_tREFI65535_ASRTC_AIDA.PNG
 
vllt. auch wieder neue sicherheitspatches, die das jetzt erstmal die neue normalität werden lassen? im test-windows hab ich hier auch seit heute andere langsamere werte als im haupt-win. und auch andere updates, da preview kanal. das haupt-win ist ein normales im standard update kanal, hier sind die werte bisher wie immer & es stehen glücklicherweise keine updates an. das resultiert in 68gb / 67gb / 69gb im test-win vs 72gb / 68gb / 74gb im hauptwin.

mistmistmist... ich hatte da oben (edit: im vorherigen post mit dem eigentlich schönen 4300 CL15 setting 😇) die temperatur-variable vergessen. bei gekipptem fenster war die natürlich 'wunderbar zu niedrig' :rolleyes2: (edit: die RAM temperatur muss sich für meine anwendungen etc. sozusagen auch mal entfalten können und hier mehr als 45°C erreichen dürfen, bevor ich das als mMn für meine situationen passend stabil betrachten kann. mehr temperatur haben sie bisher wassergekühlt nie gesehen und erfahrungen zeigten auch, dass um die 40°C bei meinen b-dies bei unpassenden spannungen oder timings fehler auftauchen können.) als mir das dann auffiel, wurde kurzfristig mit einem fön nachgeholfen, weil ich im betrieb (edit: während des testens) den RAM wasserkühlblock nicht herunternehmen wollte. uuuund *ZakK*, nach zwei minuten ab 38°C schon fehler (edit: maximale RAM temp bei riegel zwei liegt im screenshot bei knapp 36°C).
nun erstmal zum weiteren testen drei gewindegänge beim RAM block gelockert und nur leicht angehoben, das reicht und er kann schnell wieder aufgesetzt werden. sonst bringt's nix. grmpf... bin nun doch lieber wieder auf 4300-CL16 gegangen. ab ca 55°C kommen dort dann fehler, das darf mir gerne egal sein :) das wird nichtmal im hochsommer stören, da war das höchste um die 40°C, bei... 32-34°C? wasser gewesen, irgendwie sowas.

@ShirKhan: okay, ich mach mal schnell screens :d
 
Zuletzt bearbeitet:
ich hatte da oben die temperatur-variable vergessen, bei gekipptem fenster war die natürlich wunderbar zu niedrig :rolleyes2: als mir das dann auffiel, wurde kurzfristig mit einem fön nachgeholfen, weil ich im Betrieb den kühlblock nicht herunternehmen wollte. uuuund *ZakK*, ab 38°C schon fehler. :ROFLMAO:
nun erstmal zum weiteren testen drei gewindegänge beim RAM block gelockert und nur leicht angehoben, das reicht und er kann schnell wieder aufgesetzt werden. sonst bringt's nix.
Ehm, hab ich Posts von dir verpasst oder muss man auch so kapieren, was du gerade treibst? Versteh nur Bahnhof. 🙃
 
nee, hast du nicht: schau dir mal die RAM temperaturen von dem 4300cl15 1.6V screenshot zwischenstand an. mit "ich hatte da oben" ist gemeint "ich hatte da oben (in meinem vorherigen post)" :). das war halt überhaupt nicht stabil, oder wenn, dann nur bis ca. 38°C. es war einfach zu kühl für ernsthaftes testen, ab 38-42°C steigt mein RAM kit hier bei gewissen zu niedrigen settings aus (trfc zB). darum ist RAM wasserkühlblock hier lösen nötig, um mehr temperatur generieren zu lassen. vor der block-entfernung hab ich stümperhaft als spontane "lösung" versucht, mit dem fön das ganze system zu erhitzen, um von 36°C auf mind. 38°C, besser 43-45°C zu kommen => um das ganze dann als wirklich stable betrachten zu können. sry, hast schon recht, der post kam ziemlich bröckelig und unsortiert daher ;) abends wirds manchmal schwer, das hirn zu ernsthafter kooperation zu überreden :fresse:

bzgl. mlc, updates und andere werte: mlc 3.10 verursacht mittlerweile einen bluescreen bei mir :eek: 3.11 läuft, hat allerdings jetzt auch eine höhere latenz (vorher waren es 41.2) als aida64 :hmm: aida64 werte haben sich ebenfalls leicht verändert: zwischenzeitlich kam hier aber nur ein windows security defender etc update 'rein. ist es das ggf., hat ms tats. noch weitere cpu fixes o.ä. da eingebaut? irgendwo hab ich da vor kurzem etwas darüber gelesen, dass performance einbrüche mit einem der security updates durch weitere cpu security patches kommen könnten. passen würde es ja, kann es nur leider nicht mehr nachvollziehen wo ich das las, zeitpunkt war aber ca. vor einer woche. naja, erstmal egal, wird sich schon irgendwann wieder regulieren hoffe ich doch, das haben ja mittlerweile drei leute hier festgestellt.

hier der aida und mlc screen vom 4300-cl16 setup, screenshot aus dem haupt-win, welches vollgestopft mit treibern und software ist:
Screenshot 2023-12-16 224528.png

leider hab ich von dem bench der vor dem security update lief keinen screenshot erstellt. das hätte schön die änderungen dokumentiert.

edit: aber hier noch ein screenshot aus dem testwindows, da ich im anderen den asrock TC nicht installiert habe.
ebenfalls mlc 3.11 und aida64:
Screenshot 2023-12-16 232131.png
leicht anderes ergebnis, auch gegenüber dem vorherigen aus dem selben system :shot:

dieses update oder das davor dürfte es gewesen sein, sonst kann ich mir das nicht anders erklären? kann noch jmd. das vllt. gegenchecken? sonst kam heute nichts weiter an updates hier an, bei euch vllt. noch? die sind aus dem hauptsystem:
Security Intelligence-Update für Microsoft Defender Antivirus – KB2267602 (Version 1.403.607.0) – Aktueller Kanal (Allgemein)
Security Intelligence-Update für Microsoft Defender Antivirus – KB2267602 (Version 1.403.577.0) – Aktueller Kanal (Allgemein)

und das aus dem testsystem:
Update für Windows Security platform-Antischadsoftwareplattform – KB5007651 (Version 1.0.2306.10002)

zustzl. kam im testsystem noch das hier 'rein:
treiber: Micro-Star INT'L CO., LTD. - System - 1.0.0.12
qualitätsupdate: 2023-12 Kumulatives Update für Windows 11 Version 23H2 für x64-basierte Systeme (KB5033375)
 
Zuletzt bearbeitet:
hier der aida und mlc screen vom 4300-cl16 setup, screenshot aus dem haupt-win, welches vollgestopft mit treibern und software ist:
Ok, da komm ich nicht ran. (y) Aber ich kann mich ja immer mit der schwächeren CPU rausreden. Hier ein Run mit Volldampf, 6 GHz, aber ohne HT und E-Cores. Da zischt der AIDA-Benchmark nur so durch! ^^

4300-16@6000.PNG


dieses update oder das davor dürfte es gewesen sein, sonst kann ich mir das nicht anders erklären? kann noch jmd. das vllt. gegenchecken?

Das ergibt alles keinen Sinn. :hmm: Hab gerade eine Win-10-Iso frisch installiert, vor einem Monat runtergeladen, kein Netzwerk, keine Updates. MLC sagt trotzdem 52 ns. Der Durchsatz ist schlecht, weil nötige Treiber fehlen. Nach dem Updaten bleibt die Latenz bei über 51, der Durchsatz steigt.

Win10_frisch.PNG

Mindestens ein Monat alt, wie gesagt. Und ne 42er Latenz hatte ich noch vor einer Woche, hier: #11.111.
 
Zuletzt bearbeitet:
nee, nicht wirklich @ sinn. das hier weist darauf hin, dass es durch nicht aktivierte sicherheitsfeatures entsteht. könnte sogar hinkommen (haupt-win alles aktiv, test-win virtualisierungsbezogenes deaktiviert), zumindest zum teil. es steht dann immer noch die frage im raum, warum das bei 22h2 images ebenfalls auftaucht. da kann ja eigtl. nur ein update, das eigtl. für volle kompatibilität version 23h2 benötigt aber trotzdem in 22h2 zwanghaft installiert wird, irgendwie querschießen. unbemerkt? da war doch auch etwas zu lesen: ms schiebt updates 'raus, die nicht im updateverlauf sichtbar sind. keine ahnung...
zudem hat hier das hauptwindows das 23h2 update schon seit einer weile installiert, das problemchen tauchte aber erst gestern abend auf. im haupt-win sind allerdings auch alle sicherheitsfeatures aktiviert inkl. der speicher integrität und dem hw gestützten stapelschutz. im testwindows nicht. @ShirKhan @Simply1337 wie ist das bei euch eingestellt, sicherheitskram aus oder an? ich könnt mir vorstellen, aus, da diese sicherheitsfeatures angeschaltet doch eigtl. performancemindernd sein sollten. nun ist's halt seit neuestem andersherum. ggf. kalkül seitens ms :fresse:
ich hüpf nun mal fix in's test windows (nach einem backup) und teste da mal noch ein wenig bzgl. dieser problematik herum, vllt. kommt ja was brauchbares 'raus... juhuuh, ich hab'ne mission, danke, microsoft...

moin :wink: :d


edit: ja wow, im test-win funktioniert MLC nun nicht mehr, es gibt immer einen bsod mit "system_service_exception - mlcdrv.sys" während des latenz-tests. im haupt-win alles wie es soll lol. durchsätze in aida liegen aber wieder ca. auf standard niveau, wenn man die genannten sicherheitsfeatures in windows aktiviert. wäre ja wirklich ungut, wenn das nun bei deaktivierung dauerhaft solche auswirkungen haben würde.
 
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