Overclock.net banner
10681 - 10700 of 10751 Posts

·
Registered
Joined
·
204 Posts
Try to reseat the CPU.

If I were to choose between either the motherboard or the CPU being the cause I would probably pick the CPU, but thats just going on a hunch.

Very much doubt you were unfortunate enough to have two different types of dimms that show the same issue.


Are you using 24/7 settings or your benchmark settings for that run ?

Have only ever run Sandra with my 24/7 settings.

@Veii I imagine that score of yours, 95.92GB/s, is a bugged run ??

I have one like that from my x370 motherboard

Details for Result ID AMD Ryzen 5 3600 6-Core Processor (6C 12T 4.52GHz, 1.91GHz IMC, 6x 512kB L2, 2x 16MB L3) - 95.99GB/s
So it's time to drain my whole loop and go again xD

Just before I do this can anyone explain how or why the CPU might cause this?
 

·
Registered
Joined
·
582 Posts
  • Rep+
Reactions: Veii

·
Old to Overclock.net
Joined
·
347 Posts
Guys, could somebody help with training settings? TM5 gives me 3 errors in 25 cycles - 4,9,14
vDIMM 1.42v. Tried 1.38V and 1.4V before - tm5 ended with error 2.
2518323
 

·
Registered
Joined
·
204 Posts
Guys, could somebody help with training settings? TM5 gives me 3 errors in 25 cycles - 4,9,14
vDIMM 1.42v. Tried 1.38V and 1.4V before - tm5 ended with error 2.
View attachment 2518323
You might need to pump VDIMM up to 1.45v for that bin at CL16 and I'd also run the DrvStr on auto at first or maybe 24/20/24/24. Put ProcODT back to 40 or 43.6 whilst doing that as well.

I'm no expert, but the main thing I'd try first is getting a reasonably tight main and secondary timing set stable on as close to auto settings as possible when it comes to the right hand side with ZenTimings. Leave more of the tinkering with resistances when you are trying to really tighten up, drop CL or maybe give 1T a go with GDM off.
 

·
Old to Overclock.net
Joined
·
347 Posts
You might need to pump VDIMM up to 1.45v for that bin at CL16 and I'd also run the DrvStr on auto at first or maybe 24/20/24/24. Put ProcODT back to 40 or 43.6 whilst doing that as well.

I'm no expert, but the main thing I'd try first is getting a reasonably tight main and secondary timing set stable on as close to auto settings as possible when it comes to the right hand side with ZenTimings. Leave more of the tinkering with resistances when you are trying to really tighten up, drop CL or maybe give 1T a go with GDM off.
That's what auto set me to - 43.6, 24/24/24/24.
HCI Memtest is 2000% stable though.
Couldn't stabilize tRCDRD at 16, no matter what voltage I threw on it
2518331
Does it mean TM5 is more "robust"?

P.S. Made my assumptions back from my intel tests
2518330

That is vDIMM 1.425.
 

·
Registered
Joined
·
267 Posts
well, i cant pass y-cruncher with any less IOD/CCD voltage ranges.
and for sure cant stay in windows with anymore cLDO_VDDP voltage as i hard crash no BDOS/GSOD
no WHEA 18 logged or anything of the sort.
Hmmm, 30417 is basically like 1901MHz FCLK so if it was consistent it is like BCLK or just FCLK was a little higher than set. Or it was set and I missed that part.

I don't know that I had tweaked all the miscellaneous unlocked settings in the mod bios 1.60 to full benefit, plus my testing amount went down a lot recently, heh.
 

·
Overclock the World
Joined
·
2,969 Posts
(anything over 930mv on CLDO_VDDP crashes the machine) no matter if i use 50mv stepping
all the way to 70mv stepping hitting the "max" iod ccd voltage ranges that i have bookmarked as
a recommended value to not go over....needless to say, i think anything "under" 2000fclk ill be able to do
before long, but its still not 2000 🥺
It might have a chance :)
I had at the very very start CCD issues beyond 940mV
IO Error #19 you won't likely be able to resolve, till we get it correctly nailed down and inspect more of our brolken dual ccd units ~ to find a pattern
Unless they swapped factory or GLFO has internal production line issues ~ such should not vary thaat much
WHEA is not an IMC error for sure. A bad IMC will refuse to post or only error #6 & error clearly on y-cruncher FFT

might i ask, whats bad for it this way?
Disabling C-State generation, fixes the CPU at P0 powerstate = 3.7 or 3.8Ghz
Then does PBO boost upwards yet falls back to 3.7Ghz
This is as so problematic, because 3.7 requires around 1025-1100mV sustained ~ to keep cores alive.
You lose at absolute minimum 20W from the powerbudget or 200mV in potential savings (per core so to say)
You also lose the ability to have dLDO averager function & it won't put cores to hibernation or parking without this functionality

Cores do not have to join lowest P3 state (sub 550mhz) in order to be parked or hibernated (sleeping is deep suspension, sorry for the confusing of words)
They don't have to drop to 900-920mV in order to be qualified as "parkable" ~ soo "technically" Vermeer doesn't need powerplans
But without this feature enabled, not only are the powerstep jumps too harsh (if they even function bellow P0 state) , but you waste far to much powerdraw for nothing
6 core units are already soo restrictive in their by AMD defined specs ~ and dual CCD units require it + CPPC in order to keep signal integrity high

It has only negative effects not using it ~ technically also not using DF-C States but nothing we can do against Overboost Bugs till AMD fixes it hopefully with 1203B or 1.3.0.0
Well, the Patriot Viper PVS416G440C9K arrived, 4 sticks. Serials are... close to sequential, there's 1 box between their numbers. Confirmed A2 PCB with extra capacitors, like Buildzoid's sets are, testing on C6H and 3900x before swapping into the watercooling setup, the Team Dark Pro B-die in the water rig now are so good I'll be surprised if the Vipers can beat them.
Good success !
If you need RTT values to test as 4x A2 on Daisy Chain is painful ~ just complain in this thread
I understand the CPU, motherboard and the different RAM kits are a major handicap to the RAM overclocking. I'm curious if there's still a way to go beyond the current 2933 MHz setting.
Take a read here
cLDO_VDDP is very important for Summit Ridge and Pinnacle Ridge :)
A B350 board can run +3600MT/s easily , likely even 3733+
People overjudge these entry level boards ~ it's nearly always user error
Grab TM5 to test things. https://www.overclock.net/attachments/tm5-zip.341454/
It's good to know "you error" but this knowledge helps nobody.
Get this thing and look up the error descriptions here:
I was asking once how to set RTT_WR to non-auto, if it just doesn't post. Do I have to force tCKE off from 1 to enable powerdown?
Usually no, tCKE in combination with RTT_WR makes issues
Same as CAD_BUS TIMINGs do ~ but they coexist together with a lot of work

RTT_WR changes NOM and PARK behaviour once you enable or change it's strengthness
I do have a feeling /2 requires high VDIMM-IN to even function, but /3 has to run close to always
Using RTT_WR generally has a RTT_PARK range. Barely any influence to RTT_NOM
If WR trows errors ~ it's because WR keeps autocorrecting and something bothers it. Be it too low ClkDrvStr , tCKE usage or SETUP Times usage
If it fully refuses to post - either PARK is too strong , or non existent
I'd need an example of what doesn't work for you :)
automation script to collect per-cycle screenshots with information if there were any errors
A screenshot tool that barely uses RAM would be really helpful for it.
It's beyond me why TM5 never get's updated to log better before a BSOD or reboot corrupts the log.txt ~ but that's the dev's problem :)
Notice how that document doesn't contain word "dataset" at all 😅 And segment length from the first glance can only be related to buffer size used, as segment length describes parts of TL-DRAM (tiered DRAM), that is, DRAM caching. I don't even know if it's really implemented in consumer products or not. But if it is, smaller buffer sizes might fit into caches, while dataset as a whole never would.
mmm, personal wording vs public phrasing
I need to work on it. Am no engineer (not directly, methodology is a bit different than engineers one)
Not sure if this question was inspired by me mentioning the "gap", but I took my advice from @Veii who said a 0.5 difference between VSOC and VDDG is required for optimal running.
40mV
50mV stepping is Matisse, while according to The Stilt's extensive research, it's 42mV before hard crash, but AMD's behaviour was 50mV
Vermeer is 40mV, or any fixed mV stepping - as long as consistency remains and you scale that up
Almost 0.5ns Gain over the last timings set.
How's actually the progress for you fighting against the latency loss ?
Here is ZenTimings for where I am definitely stable(TM5 anta777extreme, Karhu 5000%+), docp enabled but dropped to 3666. DRAM voltage at 1.4
2518336

Any thoughts or suggestions?
You won't like this reponse :D
cLDO_VDDP is far to high
Match it as absolute minimum with VDDG CCD, which if really stable on stock ~ looks fine at 950mV
It is influencing at what MCLK you can post but lower is always better ~ as it allows for lower procODT to function (if remain powering is correct)

Is this 4x8GB Micron Rev.E ?
Or maybe Hynix CJR ?

You want to push ClkDrvStr to something along the lines of 30-20-30-20 for the start
Maybe 40-20-30-24 if the board struggles with 4 dimms

You also want to work GDM away and start your foundation as GMD off 2T ~ yes it's faster , and saves time for you
Give SD,DD's a try as 1-4-4-1-6-6 (tRDRD = 4-4)
In the ASUS Bios go to Tools - ASUS SPD-Z , disable first both armory crates and other asus spyware (if something more is left) & read out the XMP profiles
The Bios will generate tCCD_L value for you. Remember it , it is important
Check all 4 dimms if they have the same tCCD_L value
If it's 6, then use tRRD_S * tCCDL (6) = 42 for you.
If it's 7 , then you likely are looking at 49 as a value

Let us know which ICs these are , then we can talk about a baseline :)
For tRAS as a baseline you want tRCD*2 + tCCD_L . This will always work, doesn't matter how bad the kit is.
Then tRC = tRP + tRAS (which will also always work if tRAS is correct to begin with)
@Veii I imagine that score of yours, 95.92GB/s, is a bugged run ??
I think it was legit, but looking at March ~ it might have been a 4.95+ Ghz run + BCLK 102
At the time i didn't have any Patch-D bios and played around how to exceed 1.1.0.0A functionality
Yet BAR mode and Curve optimizer functioned fully (aside from all the marketing nonsense and disagreenment)
This was 1202 with the cache boost then
2518337

It's close, but i have focused on something else - likely it doesn't show the best potential usecases
Didn't even notice 95 was "a lot" at this point of time
Was just comparing Inter-Core Latencies and where throttle really happens ++ how powerplans scale up
Was also trying to see why Inter-Thread can not be lower than 9.5ns & breaking 20ns wall ~ yea about that, been some time / haven't score focused benched on it
2518338

2518340

^ same day as above

2518339

^ this one was from February, 12th (to this day i haven't beaten my multi score lol)
This was from 28th of November, where i played between minimum Idle states learning the overboost "bug"
7% idle state was the best result on 4.65 stock
2518341
This was near the end of February and could match. Yes i was playing with BLCK and how i noticed that RC03 CTR Core-Layout Remap, "broke" my first core
But i am sure, i've never run CTR + SiSandra
Never really had "bugs" with SiSandra , but i surely played a lot of with powerplans and utilizing overboost (maan i need to finish my powerplan someday zZZ)

Sadly i corrupted at the end my main install and lost quite a few pictures. Wiping then Twitter to free up the nametag also didn't help the issue much
Seems like i have to score a 100GB/s result, to be happy these days ^^#
==============================================================
Aaa soo many pings, i can't find the message about the vcore offset question 😐 excuse me,
Pretty much the reason i use it, aside from having a unit with broken V/F curve for the cores (soo fixing it that way, as it was designed/binned for a 5950X to begin with)
Is to match board specific vdroop. Generally fight against ripple by using more droopy loadline + slight positive vcore offset ~ matching VID as close as possible to V-TEL (applied telemetry voltage) for the CPU
There are droops, and alone by using +5mV positive offset, you reset any preconfigured curves or other board-partner cheating shenanigans, that are there
Some need positive offsets, some need negative offsets

Mostly board specific what works for you the best
Early on i used +60mV added voltage ontop of -30 Allcore CO.
But 1usmus's CTR CO method based upon AMD resources (figured out myself) is a better scaling. Soo i just use 10mv more to flatten out VID droop + loadline , with supplied vcore
2518342

Keep in mind, VDROOP you get on little amount cores (less VRM Amperage Strain) vs what you get on an allcore @ high current (a lot of A-Strain)
Then also both loads between high voltage allcore vs low voltage allcore
all of these will have different vdroop behavior ~ up to VRMs capabilities & DrMos balancing.

You'd need to be cautious when you use this behavior to really tune it for all the voltage ranges.
Even when PX boost has no droop, an allcore full throttle load can then have negative effects.

I mostly use it again "for balancing and board tuning" these days
Early on as CurveOptimizer support - but now it's not needed after figuring out how Yuri works :)
 
  • Rep+
Reactions: XPEHOPE3

·
Overclock the World
Joined
·
2,969 Posts
Boost Override do influence.
Yes sadly :(
You are correct. This complicates it a bit without reason

Good to know, i never noticed it ~ ty :)
Guys, could somebody help with training settings? TM5 gives me 3 errors in 25 cycles - 4,9,14
vDIMM 1.42v. Tried 1.38V and 1.4V before - tm5 ended with error 2.
View attachment 2518323
#4 is a PCB crash, either by overcurrent or by bad RTT values
#2's are fine, you can work them away
#4 are more serious
Also you want to match tRP to tRCDavg
Either drop tRCD_WR to 15, or increase tRP to 17
You should also give 1-4-4-1-6-6 SD,DD's a try at first

Powering issue looks to be it for you
Soo give 30-20-30-20 a try with your current VDIMM
#4 you have to get away first :)
Generally #6, #0, #12, #4 are bad and need to be taken away first. It doesn't matter if later more errors appear
 

·
Registered
Joined
·
6 Posts
My mismatched 48GB RAM kit (4 sticks) with my Ryzen 1600 and Asrock B450m Pro4 (1.40V DRAM limitation by the board)

The motherboard uses a daisy chain topography for the memory slots. I put the 3600 MHz kit in the "slower" slots.

I've been tightening down the timings at 2933 MHz and currently testing 16-17-16-16-26-54 with gear down mode disabled at T1 command rate. Once I finish tightening the primary timings, I'll start on the secondary ones.

Even when I tried loosing timing to something like 18-22-22-22, 3200 MHz isn't stable. 3000 MHz wasn't stable even with the original 16-18-18-36-54 timings. Tcas at 15 crashes and tRCDRD at 16 causes the OS to BSOD but tRCDWR at 16 works fine.

All of the RTT_PARK, RTT_NOM, RTT_WR, CAD_BUS (CLKDrvStr/AddrCmdDrvStr/CsOdtDrvStr/CKEDrvStr), VDDP, CLDO_VDDP, and SOC voltage have been set to default or auto as I'm not sure of what vaules to start with. ProcODT is 53.3 Ohms, which was set by the original XMP timing or by the motherboard when it was training the RAM.

I could use the Dram calculator for the starting point, but I don't trust its calculation when it said that it doesn't support Micron's B-die and it's not designed for two pairs of mismatched RAM.
 

·
Registered
Joined
·
81 Posts
How's actually the progress for you fighting against the latency loss ?
Actually petty bad ;);)
tRC anything lower than 55 just wont post. I suspect of TRDWR...
I cant lower my tRP to 17 because the 1,5v cap of my board, even loosening secundaries (i didnt test with higher tRFC).
I was only able to reduce tRAS to 38 and tRC to 56 (with tRP 18).
I'm thinking in lower my SCL's and adjust my TRDWR/RD timings.
 

·
Overclock the World
Joined
·
2,969 Posts
Actually petty bad ;);)
tRC anything lower than 55 just wont post. I suspect of TRDWR...
I cant lower my tRP to 17 because the 1,5v cap of my board, even loosening secundaries (i didnt test with higher tRFC).
I was only able to reduce tRAS to 38 and tRC to 56 (with tRP 18).
I'm thinking in lower my SCL's and adjust my TRDWR/RD timings.
Screenshot ?
You shouldn't need anywhere near that voltage
tRRD tWTR bump does nothing ?
tWR bump usually helps with "less" voltage
 

·
Registered
Joined
·
81 Posts
Screenshot ?
You shouldn't need anywhere near that voltage
tRRD tWTR bump does nothing ?
tWR bump usually helps with "less" voltage
2518356


I'm using this for now, 1,5v is needed on CL15, but seems that i'll have to go CL16 if i want to lower tRTP, i didnt test with loosening TWR, only tRDD/tWTR
 

·
Overclock the World
Joined
·
2,969 Posts
View attachment 2518356

I'm using this for now, 1,5v is needed on CL15, but seems that i'll have to go CL16 if i want to lower tRTP, i didnt test with loosening TWR, only tRDD/tWTR
Is 240ns your tRFC wall ?
You can just run more of everything, more tWR, more tRTP
And then use tRCD 20 + for example 12 tRTP
Depends, i am not sure what you run

But i see 1.5v on RTT 005, which is quite some dangerous path you take :)
 
  • Rep+
Reactions: byDenoso

·
Registered
Joined
·
81 Posts
Is 240ns your tRFC wall ?
You can just run more of everything, more tWR, more tRTP
And then use tRCD 20 + for example 12 tRTP
Depends, i am not sure what you run

But i see 1.5v on RTT 005, which is quite some dangerous path you take :)
2518357



I drop to CL16 until i get tRP17 stable. Now i'm getting error 0 and 4, i'll lower VDIMM and fix my RTT (7 / 0 / 6 is good i think).


Is 240ns your tRFC wall ?
Actually i'm almost sure than the wall is on 230ns.
 

·
Overclock the World
Joined
·
2,969 Posts
2518357



I drop to CL16 until i get tRP17 stable. Now i'm getting error 0 and 4, i'll lower VDIMM and fix my RTT (7 / 0 / 6 is good i think).
This is not a primaries issue
Pasted that way - typical cloudflare photodna nonsense

Mirror move is a transition issue between dimms
Give tRRD 6-8
tWTR 5-14 a try and report back
Also increase tRDWR to 11 for now
 

Attachments

  • Rep+
Reactions: byDenoso

·
Registered
Joined
·
81 Posts
2518359


Now i'm getting these errors, sry taking so long, i was in a "blue screen heaven" (until i adjusted CAD_BUS, RTT's, CLDO_Vddp and VDIMM).
 

·
Overclock the World
Joined
·
2,969 Posts
View attachment 2518359

Now i'm getting these errors, sry taking so long, i was in a "blue screen heaven" (until i adjusted CAD_BUS, RTT's, CLDO_Vddp and VDIMM).
Now you actually do have powering issues :)
#4
Give a pure 705 a try, else 706 it is
 

·
Registered
B550 gaming edge, 5800x, 5600x, 3600xt, 1600AF, 2070S, 4x8 3200c14, 2tb adata 8200sx PRO, 500gb 970e
Joined
·
570 Posts
Unless they swapped factory or GLFO has internal production line issues ~ such should not vary thaat much
WHEA is not an IMC error for sure. A bad IMC will refuse to post or only error #6 & error clearly on y-cruncher FFT
i tried for a while, and lowered the 'overall' WHEA 19s down from 10,000 within 5 hours time to
around 300 or so at 4000/2000, and i actually manage to post and have no crashing issues up-to 1.000 cLDO_VDDP
while im not running this in no way shape or form, it wasnt "better" in countering my WHEA 19 issue at 2000fclk.
thus after a few hours of trying/failing i reverted back to 3800/1900c14-14
(EDIT) performance was ON PAR with what it should be,
and wasnt causing issues as usual, but the WHEA 19s im more so worried about causing issues.

Disabling C-State generation, fixes the CPU at P0 powerstate = 3.7 or 3.8Ghz
Then does PBO boost upwards yet falls back to 3.7Ghz
This is as so problematic, because 3.7 requires around 1025-1100mV sustained ~ to keep cores alive.
so if core c6 state is on, then thats "GOOD" and what im after, thus making sure "PACKAGE C6 State" is off
in zenstates? pic below is (what is setting at boot) opened hwinfo to show c states being "active"

2518363


You lose at absolute minimum 20W from the powerbudget or 200mV in potential savings (per core so to say)
You also lose the ability to have dLDO averager function & it won't put cores to hibernation or parking without this functionality
couldnt this "overtime" cause some degradation? i know its not using "max" voltage but still its keeping voltage current
"steady" at all times above the idle state minimum preferred when cores are parked vs unparked?

(btw) most the 5600x shots ive seen seem extremely similar to what scores (with 200mhz oc)
get as mine was, *i dont have any previous screenshots of mine atm but they are back in this thread,
will add it if i manage to find it.
but in the process of packing up for a move to ohio.... tomorrows
the last day in Ky (31 years) hopefully this will introduce better opportunities....
 

·
Overclock the World
Joined
·
2,969 Posts
so if core c6 state is on, then thats "GOOD" and what im after, thus making sure "PACKAGE C6 State" is off
in zenstates? pic below is (what is setting at boot) opened hwinfo to show c states being "active"
Yes
couldnt this "overtime" cause some degradation? i know its not using "max" voltage but still its keeping voltage current
P0 is binned to be low and constant, same as CTR's p1 was at 1.15v ~ close to nothing can cause a degradation that way
hopefully this will introduce better opportunities....
I wish you only the best~
 
10681 - 10700 of 10751 Posts
Top