[Sammelthread] Intel DDR5 RAM OC Thread

muss ich mal durchgehen, denke aber der Großteil ist schon so eingestellt.

das ist nicht out of the box so , und ich weis auch nicht 100% obs richtig ist, viele nehmen andere settings aber auch einige gleiche - ich hab das bisher immer so eingestellt bin aber auch kein pro pro beim ram oc daher die frage an veii der hat da mehr plan als ich.

BEI MIR , sind einige oc's mit den oben genannten settings halt durchgelaufen und ohne den settings nicht
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das ist nicht out of the box so , und ich weis auch nicht 100% obs richtig ist, viele nehmen andere settings aber auch einige gleiche - ich hab das bisher immer so eingestellt bin aber auch kein pro pro beim ram oc daher die frage an veii der hat da mehr plan als ich.
fast boot > off - check
mrc fast boot > off - check
VDDQ training > on - off im Moment
Round Trip Latency > off - check
SenseAmp Offset Training > off - check
Turn Around Timing Training > off - check
DIMM DFE Training > Jetzt beide off
MCH Fullcheck > off - check
UnderVolt Protection > on - check
 
Zuletzt bearbeitet:
Status Update:

CMDVrefDn:

20=2.5b error
10=2.5b error
30=BSOD
40=2.5b error
50=2x training loop, 2.5b 45.284s VST error 7. minute
60=2.5b 45.328s VT3 error 14. minute
70=2.5b 45.362s 22. minute pass, 1.25/1.39 bits/sec *10^10 ///EDIT: VST error
///Edit: 80= 38 minute later error


50 is very fast, but it makes mistakes.
60 is a little slower, but they also have their faults.
70 seems good, I stopped after 22 minutes.
If it goes like this, I'll have to slowly check it again with a 6 hour run.
There is a small gain, it shows bits/sec, but if I drive at the limit, there will be a chance to make a mistake.
I interpret it as experiencing the "safety reserves".

///Edit:
Back to auto,
I check it on a 90-minute run, so it's good.
Sorry, I can't find this. I have included the new pictures.
 

Anhänge

  • 50.jpg
    50.jpg
    718,7 KB · Aufrufe: 48
  • 60.jpg
    60.jpg
    720,3 KB · Aufrufe: 47
  • 70.jpg
    70.jpg
    747,6 KB · Aufrufe: 42
  • 80.jpg
    80.jpg
    728 KB · Aufrufe: 42
  • auto.jpg
    auto.jpg
    761,7 KB · Aufrufe: 59
Zuletzt bearbeitet:
Super, thx.


Currently yes, but I would like to find the other values with small steps. Time...

I found a starting point here, and then I varied them a lot. I measured the time, when, with which, how quickly it gives an error. That's why I wrote that they are not 100%, but they mean a lot to me.

I don't know any information about them unfortunately.


One more thing.
Today I briefly tried running the Y at base frequency to see real, non-downclocked numbers.
The Vcore was low, so it didn't make an error, but simply froze later. It's not interesting, I don't even want to run the cpu at 57x ever.

Numbers look nice on 57xP 44xE 48xR without overclock. OK, 24/7 stay me 54p 43e 47r
Well, I tried, but it seems like they put some protection in the BIOS. I could read it with 0080. There should be some way to read it...

Your VT3 results are very good, the Bitrate at 8000 surprises me. I think I'm at 1.40.. But I see that you have excellent cooling, which is not my case. That changes everything! Have you tuned your VF Curve? 1.3v SVID for 5.7 seems a bit high to me, have you set ACLL 0.6? Because the power draw is excellent.. Very good job
I just realized you're from Hungary. My father was from Vescés, Years ago, I authorized the government to allow the highway to pass through their land. I never went but my whole family was from there. It's something I have yet to do, but I confess that I was never able to learn to speak Hungarian. :)
 
Zuletzt bearbeitet:
I just realized you're from Hungary. My father was from Vescés, Years ago, I authorized the government to allow the highway to pass through their land. I never went but my whole family was from there. It's something I have yet to do, but I confess that I was never able to learn to speak Hungarian. :)
Hungarian is hard AF. 😊
Saw you connected me on LinkedIn. It's nice to see you there too. 😊
Beitrag automatisch zusammengeführt:

@Veii
Good morning,

You will laugh how amateur I am..
It turns out that the issue was the Vcore on the whole time, not the contact pressure, nor the dimms.
I just set the allcore load to 58x instead of the default 57x and now Y doesn't drop me in a moment...
Maybe the ring or E cores wanted a bit more juice.
So go back and raise AC_LL a little. 58X is okay in VST, but fails in SFT. Doesn't worth the extra juice.

Edit:

Changed my mind, I will try to tune on 58X.
Képernyőkép 2024-03-18 081240.png

1710754354976.png

1710754394922.png

1710754276416.png


Edit2:

1710758979770.png
 
Zuletzt bearbeitet:
@Veii Verbesserungsvorschläge ?

fast boot > off
mrc fast boot > off
VDDQ training > on
Round Trip Latency > off
SenseAmp Offset Training > off
Turn Around Timing Training > off
DIMM DFE Training >off
MCH Fullcheck > off
UnderVolt Protection > on
Von den kenn ich nur fast boot, mrc fast boot, vddq training on und mch fullcheck. Alles andere ist bei mir standard, wad es auch immer ist. Habe kein Plan was die restlichen Settings machen, bzw für was zuständig sind. 🤣
 
Wenn Jemand manuell die Spannungen gibt (vdd/q), muss vddq training aus.
Es macht Störung, falsch training wenn an ist.
Wenn ich es gut verstanden habe.
 
Your VT3 results are very good, the Bitrate at 8000 surprises me.
Thanks
Well, I tried, but it seems like they put some protection in the BIOS.
I read it with sadness. This job is not as simple as I thought.
I'm sorry now that I can't find the value of CMDVrefDn. I'll fix my post right away, Y Cruncher has an error.
I put it back to auto, 90 minutes run was restored immediately.
Have you tuned your VF Curve? 1.3v SVID for 5.7 seems a bit high to me, have you set ACLL 0.6?
Of course, but I made a special curve, deliberately for this downclocked frequency.
I used deep offsets because I didn't want the AC LL to be very low. Currently, it is not high either, 0.25
5400Mhz ~1.09V load die sense /VT3

I'm editing the post I wrote recently above.
 
es gibt wieder neue bios version fürs apex vanilla / encore :

Changelog :

- Optimization 14900KS CPU

ROG MAXIMUS Z790 APEX Test Bios 9903 (Based on 2102) LINK

ROG MAXIMUS Z790 APEX ENCORE Test Bios 9903 (Based on 1102) LINK

+ ME

LINK


quelle wie immer: HIER
 
hab ich jetzt auch gefunden, aber danke ;) anta777 denke ich mal
Läuft, bin ich mal gespannt...
Du machst mit dem 1usmus Profil nichts falsch.
Ungenügend wird es, wenn man etwas von einem Programm erwartet, dass überhaupt nicht dafür ausgelegt ist.
TM5 ist da um Powering oder Timing Transition errors zu finden.
Etwas worauf Anta's profil nicht ausgelegt ist und TM5 als solches ebenso nicht.

Wenn man voltage (discharge) stability testen möchte, geht man zu HCI/Karhu ähnlichen Tools.
// GSAT, stressapptest XOR passmark memtest DOS (100% pass)
Solch etwas ist nicht TM5's Aufgabe!

Dein Ergebniss teilt dir nur mit, dass die Spannungen für die RAM Seite aus OK sind.
Ob der Cache und QCLK mithalten kann, bzw Ring & IA supply, ist ein anderes Thema.
I'll do it tomorrow. Count on me.
I was reading your progress with Veii. Very good. Just to know, how do you manage only one value of CTL1? I mean, CMDVrefUp alone? As far as I remember, a value does not modify the other trained ones, so we would have to do tests one by one, is that right? Are these associated with your RTTs? I saw that you used some similar to those from shamino, could it be?
Bit of time off for RL shenanigans, ppls birthdays and socializing :)

Soo,
CTL1 depends purely on your powering foundation, capacity and board quality
Hence used RTTs + ODTs only work with those slopes
Now each of the 4 values influence it.
If one is bad, all are bad.

But,
There is something you can do like knowledge-guessing and pattern working.
A correct target value for VREF , has to stay within 3 values. Outside of that, it has to align within remain signals.
Its 60 lanes for memory that need to be trained and time align.

DQS & CLK align togher
CMD, CS, CA as DQ (4 links each) then get aligned ontop of each other.
Soo the outcome of this is, that CLK+DQS & DQ's get time aligned and then read or write leveled to be happening at the correct interval.

The biggest challenge is not for those little signals to align, but like BPM sync'ing a song, its for the shifting between and the (how do i say) expanding or thermal skewing/stretching, to not happen.
Hence each and everything has some sort of playroom, but values in between (even between our timings) i mean the micro delays. Those are the biggest challenge to get right.

Back on topic,
Those delays while being completely dependent on your RTT & ODT values, don't have a fixed position.
They mostly scale with the DIMMs density, amount, PCB type (we all are on A0 soo its not too bad) and potentially subzero thermals + Board Layer quality.
They aren't really "trained" values. Else training will take like on AMD a looong time and still doesnt guarantee clean or good training.
There's not really a threshold after when "its a good value". Just success or not, in boot X target.

What we can do, is throwing variables out of the way, and get the lowest functional point done. At whatever @zebra_hun RTTs are.
Then based on all 4 values we can shift them up and downwards together.
// using bit of logic outside of pure bruteforcing.
Soo focusing on what the Board trains is not important, and will be a bad influence. Placeboo effect.


Of course it would be great to get up with UP + Down, because not only all 4 CTL1's go together, but their distance to the DOWNs will shift.
Tho Down's one can expect that the Board has solid, its rather the starting point that shifts based on strain.

256^4 = 4 294 967 296 combinations :' )
To remove 2/3 of them, as they have 3 step margins.
85^4 = 49 787 136 attempts (better) haha
Out of those, lets say that over half doesnt reach over 15min.
And out of 22mil , maybe 80% don't reach over 2 hours.
Around 4.4mil combinations left . Hahaha
One line out of a million has now been completed.
By the time DDR6 comes out, maybe I'll be done. :ROFLMAO:
Close enough :d

Once we have all 4 values together, which do not depend too much between Boarddesigns (unless ODM made a design mistake, which's one can expect the apex has an exemplary tracedesign-layout)
We can shift its starting point up and down , to adapt to "whatever RTTs + ODTs are set" at whatever IC Vendor's design.
CTL0 ODT will have the CPU and SA as variables.
But DQ Vref, "the package" delay by clock , has been nailed down. Its floor and ceiling margins too.
It may have a bit of playroom up and down, between 1 DPC and 2 DPC designs, but that part is confidently nailed down.
Gear4 only is not fully checked. Someday (maybe 15th gen?) i'll inspect that part myself too. 10400 Strap is nice and all, but i see only suicide runs, not full stable runs so far.
Shifting clock in runtime (OS) vs actually training at this strap with its delays ~ is a completely different world. Something that we still miss, given (predictive) specification papers only reach 8800MT/s.
Basically long way to go still, soo basically a guaranteed flawed foundation in the current state and room to improve. :-)

I would like to know if there is any information about Data Equialization, and also about DFE Taps and profits. These are in the Gigabyte mobos, but I don't see them in Asus (Taps). Do you know if there is something to read? It's all related and more so at high speeds. I think Asus doesn't want us to go full manual.
Given education belongs free to every individual:
https://oa.mg/ & https://sci-hub.se/about ~ papers from IEEE Xplore , Harvard, Medical Studies and ongoing

You will find snippets of information between each citations of each researcher groups.
You will not find trade secrets or governmental supported organization papers, but papers by standalone neutral researchers.
But as always, what might be politically fine on one place of the earth, may be restricted on the other
brave_zSvibZo5sR.png

Your milage will vary :)
The 2ndary part of the message
Data Equialization, and also about DFE Taps and profits. These are in the Gigabyte mobos, but I don't see them in Asus (Taps).
=//=
I think Asus doesn't want us to go full manual.
This is basic power control of whoever silly-head decided that.
There is not much to say, neither a point in it. Its their decision to intentionally remove access to crucial (one of many) parts in DIMM Tuning functionality.
Gladly other Boardpartners haven't taken that silly path yet, but they only provide done presets without much of an explanation.

The current state appears that this is not the Board to do research on. Neither is AMDs locked-up platform. It is what it is.
I can only hope giving it time, this decision will be rethinked by whoever attempts to wall-off research and deny global progression;


DFE is a signal peak filtering algorithm, and reflection filtering algorithm ~ designed specifically for DDR5 high frequency.
It is an interpolated and negative filtering algorithm that tries to flatten down reflections by inserting a negative of a signal with X delay @ Y strength.
Its accurate functionality depends ontop of foundational filtering algorithms, which are CTLE , FFE and couple more :)
Big topic.

RdEqualization i haven't mastered, actually both i haven't
It is a starting and endpoint sync, and like DFE - the values may or may not shift based on Clock and "signal strength"

I'm still a novice :)
Its just unfortunate the state ASUS (Intel FW-Team) attempts to position themselves.
Give it time and keep on researching neutrally~~
Just uncalculated unfortunate business practices by whoever decided that.
// Some can be intentionally removed to prevent mistakes on "potential snowballing" variables, but i don't know. It's the way of handling it.
// It can be even that not everyone agree's and intentionally forgot to clean it up fully, till the point i shared how to access it. Where now they are gone. Or maybe coincidence as time factor.
Yea there is nothing to say more, it is whatever 🤭
 
Zuletzt bearbeitet:
Hungarian is hard AF. 😊
Saw you connected me on LinkedIn. It's nice to see you there too. 😊
Yeah. I've been reading the posts since last year, and in one you shared a drive. That's why I could see your name. Don't add you so as not to disturb. But there is nothing to hide :) I have a big part of my heart in Hungary. (Which I still don't know). I am waiting for some new 8200mdie to continue with the tests, I have already sold the a-die. We'll see how the non-RGB Xtreem turn out for me.
Beitrag automatisch zusammengeführt:

es gibt wieder neue bios version fürs apex vanilla / encore :

Changelog :

- Optimization 14900KS CPU

ROG MAXIMUS Z790 APEX Test Bios 9903 (Based on 2102) LINK

ROG MAXIMUS Z790 APEX ENCORE Test Bios 9903 (Based on 1102) LINK

+ ME

LINK


quelle wie immer: HIER
Thanks! I wonder what would be the difference. I’ve tired 0080, 0801, 1001/2, and the last 9902. So far, nothing that I’ve noticed.
Beitrag automatisch zusammengeführt:

DFE is a signal peak filtering algorithm, and reflection filtering algorithm ~ designed specifically for DDR5 high frequency.
It is an interpolated and negative filtering algorithm that tries to flatten down reflections by inserting a negative of a signal with X delay @ Y strength.
Its accurate functionality depends ontop of foundational filtering algorithms, which are CTLE , FFE and couple more :)

This is basic power control of whoever silly-head decided that.
There is not much to say, neither a point in it. Its their decision to intentionally remove access to crucial (one of many) parts in DIMM Tuning functionality.
Gladly other Boardpartners haven't taken that silly path yet, but they only provide done presets without much of an explanatio
Thanks Veii! Yes, I have seen your drawing of the data eye, where you can see the fe vref points, and if I remember correctly the blue dots, the higher the speed, the more important DFE is. I saw a video from Future Plus that explains it very well, what the distances of the taps are. At some point I thought Data EQ was related. I imagine Asus must incorporate some of this into their BIOS.

I still don't understand why 99% want 8800 with everything by car, or VDD=VDDQ. The pay2win has a very high cost, in voltages. I'm going in search of my third delta with a new mdies. I will follow in @tibcsi0407 footsteps :)

I hope you achieve 10,000 with your knowledge. Here you have a supporter!! Thank you as always for guiding us.
 
Zuletzt bearbeitet:
G'Morning :censored:
I still don't understand why 99% want 8800 with everything by car, or VDD=VDDQ. The pay2win has a very high cost, in voltages. I'm going in search of my third delta with a new mdies. I will follow in @tibcsi0407 footsteps :)

I hope you achieve 10,000 with your knowledge. Here you have a supporter!! Thank you as always for guiding us.
Because 2200MHz QCLK is not that high, like at all.
We are still at A0 PCBs, custom Iteration but mostly the same thing with here and there some VCC to Ground filtering change.
Some cost effective, some excessive. All mostly the same.
Even the so called "new" ICs are refined to be cost effective but its not really going forward to what i see. They are even a downgrade.

There is talk about CLK_(re)Drivers, but there is little talk about DataBuffers.
There is good research by Samsung on non-via's extended capacity (4gb IC) but there is no DS DR UDIMM or so called 2H (+DS) UDIMM.
There is no successful research done (i think) on (PCB) punch-through VIAs & UDIMM is just in a boring state. For me at least, i see nothing new.
There are no LGA1700 server boards that support RDIMM, neither AM5 server boards.
There is no successful approach in dual PMIC management of voltages, in improving efficiency and SNR ~ outside potentially Crucial's new lineup (which has to be tested further)

It is literally in a boring sleeping state. Or i don't notice.
I hope 15th gen doesn't take all too long.
I hope you achieve 10,000 with your knowledge. Here you have a supporter!! Thank you as always for guiding us.
This will sound like a rude hottake, but i dont think the targets are hard at all.
There are simply no stable 10400MT/s strap (Intel) results. Its not even Dual (CPU) channel.

If we take your 3 guys systems, all of them will boot 10K G4 on one dimm.
I don't know. Maybe just in a pouty mood recently.
Progression goes backwards.
AMD is just 1 year 6months in, and their Auto (locked) enforcement Team, managed to outscale Intel's FW side from 2021.

If everyone knows soo much better of the employed ppl that work for X Boardpartners, where is the progress.
How long did it take that we even have some sort of relatable scalable behavior on VDDQ, yet we lock down things further and slow down progress even more.
Even examples i see by MemoryVendors and method of tuning is, adventurous to say the least. (many, not all) . Like what are you all doing.
Everyone's soo much more talented then me and progress is ... fractional;
I don't know~
Am just in a pouty mood i guess and want to complain; :coffee:
Beitrag automatisch zusammengeführt:

@Veii Verbesserungsvorschläge ?

fast boot > off
mrc fast boot > off
VDDQ training > on
Round Trip Latency > off
SenseAmp Offset Training > off
Turn Around Timing Training > off
DIMM DFE Training >off
MCH Fullcheck > off
UnderVolt Protection > on
fast boot > off // ✅ no need for .2 sec faster DXE driver init. Up to FW-Design may influence more training durations.
mrc fast boot > off // ✅ no need to combine wakeup based training with coldboot based training (different things but seen FW bugs). Ambient temp fluctuates, training is important.
VDDQ training > on Off !
// values that depend on CVDDQ are inconsistent and dont train. They are many and remain inconsistent between each foundations. Either long training, or no bad training. No bad training preferred. Mainboard & Crystal are not that thermal sensitive on ambient, to expect Delta fluctuations.
// From consumer perspective even, much better as lookup table with AUTO IVR CVDDQ vs current inconsistency mess. All "XMP unstable" Video's have a reason to exist. Take a look how well AMD manages it and only leave MVDDQ access to the user.
// From OCer/Reseacher perspective: Just get your values right, its harder work but just do it right please.
Round Trip Latency > off AUTO !
// There is not only "good training". Good Board FW has RTLs figured out as a lookup table. "On" ignores that lookup table. Giga needs to work on it hence "on" is common, but training here has too high chance of causing issues. Only "ON" if board is derpy. ASUS HQ knows RTLs very well.
SenseAmp Offset Training > off AUTO
//
Same reason. Hynix ICs are known, PCBs are "booring" and known. Inter-IC distance to SenseAMP for Micron and for Hynix are more than known. Training variable will cause issues in charge recognition. Auto should be off+lookup table. And if FW has non, then it will have a chance to train.
Turn Around Timing Training > off AUTO
//
Same thing in black. Memory timings you see and get given, are just a fraction of what is happening under the hood. Keep it auto, so those have any chance of training. Under your terts are at least 15-20 more timings that need adjustment, else they stay at 5600 JEDEC level maaybe 6400 max in early FW state. Your milage will vary, but AUTO is correct.
DIMM DFE Training > off AUTO unless you want to test SI (quality) & purposely make your tuning life harder
// DFE on TX side , while should have a lookup table, sadly is not always the case. DFE need changes based on strain factor and filtering algo. There is no such thing as "one preset rules them all". Give it a chance to train if needed.
// DFE should not be used as bandaid for suboptimal CTLE or FFE. It comes after! it. No reason of TX DFE sub 8400MT/s. ReadEQ is ok to use. DFE is last stage. Signal shifting due to Board-issues is post bandaid then.
// Also wrong named, this is not RX DFE, but TX DFE. Unless i'm wrong and RX-DFE is just Boardpartner preset, while other would be position training. Silly tho, as position and gain go hand in hand. Don't think i'm wrong
// Only not wrong, if this is TAPs. Taps vs Gain+location is a different thing. But RX Taps is DimmVendor work. TX Taps is Boardpartner work. Still badly named then :-) AUTO is a good value.
RX (dimm receiver) DFE > AUTO if <8400-8600MT/s. ON past 8600MT/s.
// This is DIMM-Vendors work to supply DFE target of their product (+ validation file ! , is expensive i know). No need to override training by Boardpartners, but appears currently a requirement past 8400MT/s state.
MCH Fullcheck > off AUTO
//
Limiting training duration by itself, does nothing. This option has zero reason to be on "off". Lookup table values that may be enforced, already shorten training duration. ON/OFF doesnt change a thing. OFF especially has zero benefits.
UnderVolt Protection > on AUTO
//
Similar reason, it may be used as bandaid against "random low voltage" shutdowns due to problematic V/F sub 700mV. But a bandaid is never a problem resolver. No reason to mess with that option, nor limit undervolting ability.

ON = Ignore and train
AUTO = lookup table, if non , then train
OFF = lookup table or user input, if non, dont train mess
 
Zuletzt bearbeitet:
die ganzen auto settings sind richtiger müll bei mir , das training dauert länger und es geht auch deutlich weniger beim oc und dieses usmus profil bringt bei mir auch rein garnichts wenn ich das nutze hab ich mit 8800mhz erst errors , wenn ich extrem nutzen fangen die errors die tm5 wirft schon bei 8200 teilweise an (ohne optimieren)

generell nutze ich aber auch immer 2 tools teilweise sogar 3 -> tm5/karhu und vst in Kombination nacheinander

und bei undervolt protection gabs mal ein bug weswegen man das auf on gesetzt hat. (ka obs den noch gibt)
Beitrag automatisch zusammengeführt:

Neue offizielle bios version - direkt auf der herstellerseite

lFKLIKZ.png


(HIER)

3UB5Fir.png


(HIER)
 
Zuletzt bearbeitet:
Total langsam... :( aber Timings sind doch ok. :unsure:

PYPrime_32B_119.854.jpg
 
testing 1102 bios in encore and seens very gud..

vei i have an question to you
Lets hypothetically say i dont need speed at all.. 6000mt/s and 4.5ghz cpu clock speed will be same as 8000/5.4
which is kinda the case i am right now, I play games that are from 1998..
or even hypothetically another example.. I do critical tasks that requires precision & accuracy and doesnt matter speed. workstation shit

Would you change the way to configure it ?

my concern is controlling VDDQ Training off and mv delta optimize but not having 100% sure im doing a better thing than letting the board do it
i dont have an osciloscope to know if signal got less or more noisy
and those optimizations is usually only really needed for reaching higher speeds

I believe there is a reason vendors(asus) does big values to start with at Auto.. maybe it gives the signal with highest chance of being clean?

Im just wondering and very curious what is your guesses in this weird position
 
aber Timings sind doch ok. :unsure:
nuAoaPNEN3.png

RRDS 4 , FAW 16 is for 1Rx16 layout. 2 ICs not 4.
Actually not, its for RDIMM , but may function on "half-rank" layout.
All DDR5 run in BurstChop 8, not 4. This is not DDR4.
 
Zuletzt bearbeitet:
Da mein Corsair 6000C36 Kit so gut geht, aber vom PMIC eingeschränkt wird, wollte ich immer mal das 7200er Kit testen. Jetzt hab ich aber gelesen, dass die was umgestellt haben bei den Kits? Meins hat den ANPEC PMIC drauf.
Hab es schnell mal getestet mit den Timings, die ich schon mal für einen 8800 Test verwendet hatte, aber mit einem G.Skill Kit.

snaphsot0001.png


Scheint ganz brauchbar zu sein... hoff ich doch. 🤞
 
So,

habe heute mir mal die Mühe gemacht und den Contactframe runter gehauen und mit dem ILM getestet, da es mir komisch vorkommt dass das Board/cpu nur 7200 stable mitmachen.
Aber auch mit ILM sind nur 7200 Stable drin.
Genommen wurde das XMP Profil der Titanium 8000 mit runtertakten auf 7600->7400->7200.
7800 habe ich gleich übersprungen.
Timing habe bei 7600 vom Corsaor Titanium 7600 genommen, also 36-46-46-46-96-2T Ram Spannung auf 1,4

Ich kan einfach nicht glauben dass das Board bei 7200 dicht machen soll, wenn die 7800 schreiben und der RAM bei 7600 laufen soll.
 
So,

habe heute mir mal die Mühe gemacht und den Contactframe runter gehauen und mit dem ILM getestet, da es mir komisch vorkommt dass das Board/cpu nur 7200 stable mitmachen.
Aber auch mit ILM sind nur 7200 Stable drin.
Genommen wurde das XMP Profil der Titanium 8000 mit runtertakten auf 7600->7400->7200.
7800 habe ich gleich übersprungen.
Timing habe bei 7600 vom Corsaor Titanium 7600 genommen, also 36-46-46-46-96-2T Ram Spannung auf 1,4

Ich kan einfach nicht glauben dass das Board bei 7200 dicht machen soll, wenn die 7800 schreiben und der RAM bei 7600 laufen soll.
Wie sind die restlichen Spannungen, SA etc.?
 
SA liegt bei 1,28, vdd und vddq bei 1,4, vpp 1,8
An den Dimms Temperaturen lags auch nicht, die fehler traten teilweise schon bei 40°C auf.
 
Versuch doch mal mit 1.1V SA
 
gerade mit 1,1 sa getestet bei 7600 @c36 - fehler.
 
gerade mit 1,1 sa getestet bei 7600 @c36 - fehler.
V/F curve sichtbar auf deinem Hero ?

Bei "Fehler" immer Daten beilegen worauf sich das bezieht.
Bei "stabil" gilt grundsätzlich das selbe. Bilder beilegen was man genau getestet hat.

SA 1.16
IVR VDDQ 1.185 (ansonnsten 1190mV)
IVR VDD2 1.38
VDDQ MEM 1.365 (ansonnsten 1370mV)
VDD MEM 1.425 (ansonnsten 1420mV)

Wenn 7200 gerade so stabil ist (wenn überhaupt) wird das 7600 nicht plötzlich.
Der Zwischenschritt ist 7400MT/s

Viel Glück

EDIT ~ übrigens, neuestes Seiten-Bios ?
 
Zuletzt bearbeitet:
Was limitiert wahrscheinlicher? CPU oder Mainboard?
Laut QVL von ASUS sind 7600 "garantiert" - aber auf die liste gebe ich herzlich wenig.
 
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