Overclock.net banner

4101 - 4120 of 45825 Posts

·
Registered
Joined
·
1,560 Posts
So, I've stumbled upon something truly curious. Ok, so in my earlier posts I complained about default vcore being ridiculously high, and I am 125% adamant that it's not because of XFR - this was observed @ 0902 bios and 0038 bios. Well, last night, after clearing CMOS for the 20th time because of 0d Qcodes, I am seeing 1.199v in bios with everything stock, and the prior behavior went away. Now, idk what might have caused it, what changed, why this CMOS clear was any different from prior CMOS clears, why the issue originally appeared in the first place, but now my Auto (default) vcore setting at everything stock is back to normal, akin to what I first observed with the old bios with which the board came with, the first time I booted the system.

Side note: My rig is running P95 while I hear Initial D - Gas, Gas, Gas theme playing in the background. Glorious.
 

·
Registered
Joined
·
1,682 Posts
Quote:
Originally Posted by Zamoldac View Post

Any noticeable differences between 1N and 2N?
My kit will do both at 3200 but needs a lil bit more volts for 1N.
For me its always 1st thing that i change when playing around with memory. Shame still no option of changing in bios :/
 

·
Banned
Joined
·
4,627 Posts
Quote:
Originally Posted by Kriant View Post

So, I've stumbled upon something truly curious. Ok, so in my earlier posts I complained about default vcore being ridiculously high, and I am 125% adamant that it's not because of XFR - this was observed @ 0902 bios and 0038 bios. Well, last night, after clearing CMOS for the 20th time because of 0d Qcodes, I am seeing 1.199v in bios with everything stock, and the prior behavior went away. Now, idk what might have caused it, what changed, why this CMOS clear was any different from prior CMOS clears, why the issue originally appeared in the first place, but now my Auto (default) vcore setting at everything stock is back to normal, akin to what I first observed with the old bios with which the board came with, the first time I booted the system.

Side note: My rig is running P95 while I hear Initial D - Gas, Gas, Gas theme playing in the background. Glorious.
Measure with a DMM, even my voltage set to 1.238 on bios was showing as 1.199 in hwinfo. Don't trust the BIOS or software to measure voltage its not accurate, DMM is pretty accurate at the pinouts and raja pointed out measuring behind the socket or something at the vrm is even more accurate. Not sure if the new hwinfo64 beta took it into account with offsets but the 5.47-3118 seems to be dead on for me at vcore.
 

·
Registered
Joined
·
16 Posts
Ok, so i must return my ram, now i want a sugestion for 3200 mhz, low profile (i can not put gskill tident i will not fit)

Ok so i order the red ones, must wait until 5 april now..
 

·
Meddling user
Joined
·
7,423 Posts
@praz

+rep'd earlier post
smile.gif
, thank you
smile.gif
, adding all this "RAM" stuff in a section of OP in my Ryzen Essential Thread.
 

·
Premium Member
Joined
·
2,738 Posts
You are getting paranoid with the voltages. Just keep the voltages at sane levels (< 1.45V for VDDCR_CPU, < 1.10V for VDDCR_SoC) and don't tamper with the load-line settings, unless you actually MEASURE significant amounts of droop, under load (which is not likely on C6H). Voltage overshoot hurts just as bad as undershoot, when it comes to stability. If you need to increase the load-line setting (i.e. introduce overshoot) to maintain stability, then your voltages are not set correctly to begin with.

The load-line options in bios translate to:

Auto = ±0% (1.425mOhm)
Level 1 = -40% (0.855mOhm)
Level 2 = -50% (0.7125mOhm)
Level 3 = -75% (0.35625mOhm)
Level 4 = -85% (0.21375mOhm)
Level 5 = -100% (0.0000mOhm)

I personally recommend to keep the load-line settings at "Auto" at all times, unless you are doing LN2 runs.

The main difference between the different Ryzen 7-series SKUs (aside of the clocks) is the leakage. The 1700 SKUs have low leakage characteristics, while both 1700X & 1800X are high(er) leaking silicon. Because of that 1700 requires even less load-line biasing than the other two (due the currents being lower).
 

·
Registered
Joined
·
57 Posts
Fellas could use some help/clarification on OC'ing via p-state (A0-8-20) vs. muli (x40), as I'm having some difficulty getting the former stable.

I've switched back and forth b/w the two approaches a couple times now (clearing CMOS b/w each transition), and I've found a couple things I just can't explain. FYI, the only things I change in BIOS to use p-state OC are to switch multi from "40" to "auto" and key in A0-8-20 for p-state 0 (per Elmor's guidelines). Everything else (including vcore offset) stays exactly the same.

1) Temp readings on CPU Tctl are consistently 10-15C lower using p-states. Makes sense at idle (since CPU downclocks), but why on earth would this be true under load as well??? As a result of this quirk, x40 OC gives tctl temp that is ALWAYS higher than Mobo CPU (by 10C or so), but when I switch to p-state OC, the opposite is true. False temp reading? Or is there a logical explanation for this?

2) I'm finding it VERY difficult to lock down a Prime95 stable vcore using p-state OC. With x40 multi, I give vcore +.05 offset (LLC=0) and it's nigh unbreakable (12 hours new P95, IBT at max stress, 4 hours Realbench, etc.). Exact same settings on p-state and she passes everything except Prime. Subsequent voltage changes, tinkering with LLC, etc. do nothing to change this. Simply cannot get more than 2-3 hours of P95 blend without a code 8 crash using p-state OC.

I don't know enough about p-states to explain this behavior, so I was hoping some of you might have some insight. EDIT
 

·
Registered
Joined
·
721 Posts
Quote:
Originally Posted by MigM16 View Post

ok so im gonna put black on the ground and then i use red to test the points ?
Quote:
Originally Posted by Lipps ForHer View Post

yes, so long as your wires on the dmm are set for black ground and red load.
It may be worth pointing out that with any digital multimeter there will be an error in its voltage reading, just like those from the array of digital voltmeters embedded in the motherboard. The DMM's instructions should specify error levels for different measurements; I have never seen error levels reported for motherboards. We should expect that the motherboard errors could be higher due to temperature variations than those of the DMM, if the DMM is of reasonable quality. Key takeaways:

[*] Low cost DMMs are not laboratory quality.
[*] One cannot know whether the motherboard error adds to or partially cancels the DMM error.
[*] A 1% combined error among motherboard and DMM readings at 1.5 Vdc is 0.015 Vdc.

Hence, one shouldn't make too much of small differences in readings between the two sources.
 

·
Banned
Joined
·
4,627 Posts
Quote:
Originally Posted by kaseki View Post

It may be worth pointing out that with any digital multimeter there will be an error in its voltage reading, just like those from the array of digital voltmeters embedded in the motherboard. The DMM's instructions should specify error levels for different measurements; I have never seen error levels reported for motherboards. We should expect that the motherboard errors could be higher due to temperature variations than those of the DMM, if the DMM is of reasonable quality. Key takeaways:

[*] Low cost DMMs are not laboratory quality.
[*] One cannot know whether the motherboard error adds to or partially cancels the DMM error.
[*] A 1% combined error among motherboard and DMM readings at 1.5 Vdc is 0.015 Vdc.

Hence, one shouldn't make too much of small differences in readings between the two sources.
.015 isn't much, but when the mobo reports 1.2v and youre actually at 1.25 volts thats a bit more. I have a Fluke DMM so ill take it as pretty damn accurate haha.
 

·
Registered
Joined
·
83 Posts
Quote:
Originally Posted by Crowfood View Post

I appreciate the time you put into this post. I do have 4 sticks of ram but I am only running 1 of the sticks at 2133mhz. It is very good ram, the tridentz 3600mhz cl16 with samsung b-die ICs. Unfortunately I don't have another graphics card. I will spend some time on the details and see if this helps. Maybe the bios settings will help. I've build many many computers and never had a bad experience like this. Sigh. Anyways thanks again for the help. I will post any fixes if I find them.

Edit: I should have mentioned I know multiple people running rx480s on other x370 branded motherboards just fine. Including the MSi Titanium, and the Gigabyte Gaming 5. Going to give thing another day or two of debugging, if no fix I will RMA the board.
I hadn't heard from anyone running radeon, when I posted about the issues with my rx480. If anything, I think it has something to do with the drivers at this point.

But... then again, maybe it is still centered around the ram issues, and that is only affecting the radeon (more so than nvidia) in some way .
confused.gif
.
As I stated in that my "angry rant" post back a few days ago, I'm running G.SKILL Ripjaws 4 Series 32GB (4 x 8GB) DDR4 3000 (PC4 24000) Model 4-3000C15Q-32GRK

I've currently got 2 sticks running, and with the relaxed timings, thus far its still stable.
I was up past 3am this morning working on editing a video, which I still have to finish today. After I get this video done, I'm going to reinstall my other two sticks and see how that goes.

In any case, hope you get at least a working temporary solution figured out until they get a solid BIOS available.
 

·
Registered
Joined
·
17 Posts
Quote:
Originally Posted by Purple Hayz View Post

Fellas could use some help/clarification on OC'ing via p-state (A0-8-20) vs. muli (x40), as I'm having some difficulty getting the former stable.

I've switched back and forth b/w the two approaches a couple times now (clearing CMOS b/w each transition), and I've found a couple things I just can't explain. FYI, the only things I change in BIOS to use p-state OC are to switch multi from "40" to "auto" and key in A0-8-20 for p-state 0 (per Elmor's guidelines). Everything else (including vcore offset) stays exactly the same.

1) Temp readings on CPU Tctl are consistently 10-15C lower using p-states. Makes sense at idle (since CPU downclocks), but why on earth would this be true under load as well??? As a result of this quirk, x40 OC gives tctl temp that is ALWAYS higher than Mobo CPU (by 10C or so), but when I switch to p-state OC, the opposite is true. False temp reading? Or is there a logical explanation for this?

2) I'm finding it VERY difficult to lock down a Prime95 stable vcore using p-state OC. With x40 multi, I give vcore +.05 offset (LLC=0) and it's nigh unbreakable (12 hours new P95, IBT at max stress, 4 hours Realbench, etc.). Exact same settings on p-state and she passes everything except Prime. Subsequent voltage changes, tinkering with LLC, etc. do nothing to change this. Simply cannot get more than 2-3 hours of P95 blend without a code 8 crash using p-state OC.

I don't know enough about p-states to explain this behavior, so I was hoping some of you might have some insight. EDIT
As stated before post you settings so we can see and help accordingly
 

·
Registered
Joined
·
148 Posts
I see your day is going about as well as mine.
 
4101 - 4120 of 45825 Posts
Top