I am kinda of learning as I go here, so don't take what I say as coming from a well experienced and very knowledgeable fellow - am I not! :)

In HWMonitor matches with HWInfo for CPU Tdie Temperature, and the vCore shown is the same as in OpenHardwareMonitor, read from the motherboard sensor.

On auto on an X370 TaiChi and with a 1700X I had spikes of vCore over 1.45v when two threads were being used.  When 3 or more threads were being pushed the vCore would drop down some.  When all were used it'd drop to 1.2v ish.

I have manually set the Core Voltage to 1.30v in the BIOS/UEFI and set load line calibration to level 2.  Everything is stable and the monitored vCore flutuates between 1.280-1.312v depending on what use is occurring.

I will have to get the kWh meter out to measure if there is a reduction in idle consumption, because whilst the Tdie is actually lower at idle than before (and lower under both 2T / 16T loads), it just feels strange not seeing the vCore drop down when not needed - the AMD Cool 'n' Quiet thing or C-states.

However, as daytonyb has pointed out before in a longer message, the current does change.

I hope you get to the bottom of the understand like I am trying to.  Good luck.

(apologies for continuing a possible thread hijack) Well, the very fact that temps have dropped a little more makes me think it's not really a bad thing running at 1.30v constantly.

Interesting reading here:
http://www.overclock.net/t/1628508/official-ryzen-5-1600x-1600-1500x-1400-owners-club/520" rel="nofollow - http://www.overclock.net/t/1628508/official-ryzen-5-1600x-1600-1500x-1400-owners-club/520

Ah, well this is interesting.  Certainly not what I had.  Auto setting BIOS/UEFI shows that when idle the VID and vCore(s) are all sub half a volt.  It's only really when two cores/threads or less are used that the vCore goes to the 1.4+v range.

Temperatures were never high at idle-  The fact you say you have a high idle temp makes me wonder what on earth is going on.  Note settings and reset?

If I ran Prime95 with all cores and threads, my Auto voltage went to vCore of 1.20v.  However, it's when running on single or two cores (or threads) only with Prime95 is when the vCore really shot up.

We cant continue discussion on a thread I created a while ago f you like, rather than continue on this, although it does seem relevant.
http://forum.asrock.com/forum_posts.asp?TID=6185

The main point for me is that temps were not bad under auto or under fixed voltage mode.
This is interesting:
https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

VUMeter wrote: We cant continue discussion on a thread I created a while ago f you like, rather than continue on this, although it does seem relevant. http://forum.asrock.com/forum_posts.asp%3FTID=6185" rel="nofollow - http://forum.asrock.com/forum_posts.asp%3FTID=6185 The main point for me is that temps were not bad under auto or under fixed voltage mode. This is interesting: https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/" rel="nofollow - https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

VUMeter wrote: Looks like the on chip power controller does some interesting this with voltage offsets that make it hard to measure.

://

forum.asrock.com

/forum_posts.asp?TID=6185

OK, it just replaces ? with %3F, neat, helpful.

Idle 52°C !?!  Yeah, that would make me (1) turn off immediately (2) take off CPU cooler (3) clean of thermal compound (4) cry (5) think of who I could call to do it for me.

However, I'll assume you did actually apply the CPU correctly.  First time builder here, I put on an NH-U14s, and that was nerve wracking!  Thermal compound application didn't fill me with confidence (though tests showing even a 'smiley face' pattern works OK enough). Damn screws wouldn't get purchase on the threaded mounting brackets until I put some force onto them, but it's kinda scary.

The UEFI/BIOS temp is Tctrl on P3.00 and T-socket (?) on versions below.  Either way the Temp reported in BIOS isn't accurately reflecting what is going on, which makes setting fan speeds a pain!

That's seems like there is something very messed up to be getting idle temps that high though.

It's Winter here in, perpetually dreary, England and we don't have our heating on all day, only when it's really cold.  I had a small window open too, so it was about 10-12 °C in the room and the idle temp Tdie was 19.8 °C.  The Zotac Mini 1070 with fans at 30% was 24 °C!

From what I am reading, yes exactly.

The system management unit (SMU) handles distribution of voltages on the chip to all of the different areas.  It controls thermal throttling and other fancy things.  It also controls how and when and even if XFR is going to work at all.  If you change the frequency of the chip (not sure if both increase 'overclock' and decrease 'underclock' or just increase) it disables the XFR function.  For this reason it makes sense for those who overclock to at least get the same all-core overclock as their XFR single core speed, else they are at a single threaded speed penalty.

It would also seem that the SMU is a secretive box of tricks.  It doesn't seem to feed much info out to the system (or monitoring applications) about it's inner workings.  Sure there are some voltage and amperage data sensors, but they don't tell the whole truth.

From what I read from reputable sources, voltage data reported from the CPU is actually 100-150mV (0.1-0.15v) higher than is actually being distributed internally.

Now, if one sets the Motherboard voltage to a fixed amount, then the CPU may well request more (VID) but it ain't getting it.  On my chip at least 1.30v, or maybe lower, will happily support all of the CPU stock functionality including multi- and single- core XFR boosting.

Of course, there could be the odd 'dud' chip that really won't boost to single-core XFR frequencies unless it gets ~1.4v (or >1.5v supplied to the SMU), which is why all of the chips jump up to this seemingly rather drastically high voltage.

I have sent AMD Technical an email, whether I'll get a suitable reply is another question, but hopefully I'll get a definitive answer.

Why there isn't the option to control the max vCore ceiling for XFR whilst allowing for vCore reduction when idle, I don't know.  What I am going to do shortly is to play a bit more with P-states and offsets and see if I cannot coax the behaviour that I desire:

All cores idle < 1v / ~0.80v

All cores maxed ~1.20v

Single core maxed 1.30v

I have no want to keep putting 1.4-1.5v into the chip when it completely doesn't need it.

My idle temps are low, my chips boosts to 3.9GHz single and 3.5GHz all core/all thread.  This is correct behaviour.  When it boosts XFR single core it pulls almost 1.5v.  That's by design, not changeable as it's written into the SMU of the chip.

@Zlobster directly: You have something wrong somewhere that is not normal and that is creating higher than normal idle temps.  What that is I don't know and can't even begin to work out without 'playing' with it directly.

Windows is being lied to about things too.  The monitoring software is being told the frequency drops to 2000MHz on a 1700X and that's not true, the base frequency is 2200MHz (22x multiplier).  AMD hasn't said a lot but they have said Windows isn't fast enough to respond to things that the chip is doing, that or they just ain't bothering to report to the OS because the SMU is doing it.

OK, what I have just finished playing with and my results:

Idle ~0.869v @ 2200MHz

All core ~1.2v @ 3500MHz

Single core ~1.45v @ 3900MHz

Idle ~0.869v @ 2200MHz

All core ~1.150v @ 3400MHz (100MHz sslow, no XFR boost)

Single core ~1.140 @ 3400MHz (500MHz slow, no XFR)

So, I'll try to explain my findings:

Disabling CPB (XFR) means that the chip operates at it's basic multiplier speeds without turbos.  Whilst it's not a massive hit for all-core performance (drops 100MHz on a 1700X), the single-core performance takes a huge 500MHz hit.  But because 3400MHz is easily achievable on all cores, it's gonna be even easier on just one core, hence the lower vCore.

However, unless the user is gonna overclock all cores to 3900MHz or has a specific multi-core reason, disabling CPB (XFR) seems like a bad move on an -X chip.  Single core performance suffers too much.

Unfortunately we do not have control over the SMU on the chip.  So we cannot control the vCore ceiling when XFR boost is happening.  We can forcibly lock the motherboard to provide a static amount of volts, but this doesn't seem to drop down when reducing load, it stays static always.

I'd like access to the ghost P-states of XFR, but these are dealt with by the SMU on chip and not for the user to mes with.  P0 is not XFR, it is the maximum all core state.  If the P0 frequency is changed then XFR is disabled.  If P0 stays at stock frequency then the SMU is free to allow XFR boosts on all or some cores as it sees fit, and to provide whatever voltage internally that it decides too.

Now, it could be true that when manually specifying volts, the reported value in monitoring software is fairly accurate.  The SMU may have to just deal with what is available.  But when the motherboard voltage is auto, the SMU can pull more but maybe internally distribute less.

I am not a fan of this hidden working stuff, I like to see what is the real deal.  It's like these temperature offsets that aren't already programmed into the chips, just like on my old Core 2 Duo.

Sorry if this is moving off topic a bit from the original posters question.  I do hope some of it is relevant to the question though.

I think I have cracked my problem though!

P-states and Offset voltage is the key.

CPB, C-states etc all enabled as default.

P-0:

Custom 3400MHz @ 1.300v

P-1:

Custom 3000MHz @ 1.275v (same as default)

P-2:

Custom 2200MHz @ 0.900v (default) or maybe higher

In the OC Tweaker tab:

The second instance of CPU Vcore Voltage set to "offset" and start dropping it.

I've set it to -0.05v that's 50mV lower.

CPU Load-Line Calibration Level 3 (allows some vDroop)

Idle @ 2.2GHz = ~0.819v (from ~0.869v)

All cores @ 3.5GHz = ~1.160v (from ~1.2v)

Single core @ 3.8GHz = ~1.369 (from ~1.495)

This is looking promising at doing what I want.

Raising the P2 idle state a little will keep things ticking over nicely there whilst I reduce the offset further.  I may have to actually raise the P0 state back up as well, to ensure the ~1.2v is delivered for all cores, as it's quite a taxing scenario.

Not fully tested for stability, and not tested with a multimeter, so I could be being lied to, but this all looks rather good.

This seems an odd way to circumvent things though, pushing up vCore on P-states whilst globally offsetting voltage down.  In this case, are we telling the motherboard to offset what requests come from the CPU, or we just telling the motherboard to offset what it ever delivers?

I seem to have carried on my own thinking rather than perhaps helping the original poster again.  Sorry.

[edit: typeo on vCore number!!!]

When I think about it, it does make sense that the CPU could request 1.55v as the VID value read for each core through HWinfo64 goes up to 1.55v.  Coupling in some vdroop from the motherboard a spike to just over 1.5v could be seen when running single or dual core tasks and thermals are good - the max possible frequency on those two cores will be achieved and so the chip will request that voltage.

However, when I asked about fixing the voltage to 1.30v, they also said that this was safe to do.  They add that I may experience instability due to the CPU perhaps requiring extra voltage [for the fastest frequency single/dual core loads] and the fixed voltage actually starving the chip. This seems like the issue that there are some chips that are just crud from the production line, and they will actually require about 1.5v to hit 3.9GHz, so all chips are programmed to request that.  Probably most chips won't need anywhere near that voltage for single/dual core operation at those frequencies.

Recommendation is to reset to defaults and use the processor [with it's ~0.9-1.5v range].

@yodivanbaped:

You should be able to let the CPU do everything auto but fix the voltage.

On the "OC Tweaker" page in BIOS, scroll down to the "Voltage Configuration" section (underneath the RAM timings).

Put "Voltage Mode" to Standard/Normal (not Auto, and not OC mode).

Put  "CPU vCore Voltage" to "Fixed Mode"

Put "Fixed Voltage" to 1.35000

Put "CPU Load-Line Calibration" to Level 3, 4 or 5.

Do not change the frequency of the CPU or change anything else from Auto.  This will make the CPU do everything as normal, except that you are forcing the motherboard to always provide 1.35v.  It should be stable.

The reason for the load-line calibration settings is that the greater the number the LESS it compensates for vDroop (under load), but also the less it overshoots when vDroop goes away (under no load).  Level 1 and level 2 can actually put the voltage higher than the value you set, and of course overshoots can be more extreme.  Equally Level 5 might not be aggressive enough, and if your chip needs the voltage, it may get a bit less than what value you entered.

You shouldn't need to set the clock frequency - because that is not in the voltage section.  Let the chip do whatever it does automatically.

Now, P-states are an interesting topic in themselves, and can provide the efficiency of a stock processor on auto settings when idling, but also a rather monstrous overclock when the system demands it.

However, what I am trying to do is not to overclock using P-states, but maintain a stable voltage under each load condition that is accessible (idle and all-core load) whilst using the global offset of voltage to provide a negative offset of the stock auto voltage.

I know my wording is probably hard to read.

So far, I am starting to see what I want to with my offset method and haven't needed to raise the idle or -all-core voltage just yet to compensate for the global offset.  It'd be nicer if they allowed use to enter a max ceiling for the motherboard instead of just fixed mode, but I am achieving a ceiling based on offsetting from what auto uses, and what fixed mode worked at.

I upped LLC to level 3, because I feel there is a little need for some extra anti-vDroop.

Idle @ 2.2GHz ~ 0.769v

All-Core @ 3.5GHz ~ 1.112v

Single-core @ 3.9GHZ ~ 1.369v

Max temp reached with limited testing 50°C !

I ran Blender with the BMW image and it took 5m 12s (312 sec), so that's bang in line with reviews for this chip.  Cinebench ran just fine, using single, dual and all-cores.

The only program that is craptacular, is Ryzen Master.  It's a CPU hog and makes it extremely hard to measure anything because it's adding about 5-10°C to idle temps, and causing the CPU to keep jumping around.  It must be the worst coded bit of software ever.  It actually crashes during Cinebench!  The system is still fine, just that damn program ain't.

http://www.overclock.net/t/1624603/rog-crosshair-vi-overclocking-thread" rel="nofollow - http://www.overclock.net/t/1624603/rog-crosshair-vi-overclocking-thread

...The most accurate CPU Voltage reading will be from SVI2 TFN which is reporting the voltage the VRM controller is seeing. Additionally some will freak out because of seeing CPU Voltage up to 1.55V in BIOS and OS at default settings. This is the default AMD behavior when CPB is Enabled. If up to two cores are loaded, the CPU will boost to a higher frequency with higher voltage (on 1800X up to 4.1 GHz 1.55V). If more cores are loaded, the frequency and voltage will drop. It's not dangerous and as stated, AMD spec.

So it's fine!  Which is kinda what the AMD rep said in the replay to my questions.

It seems strange that there was mention of 1.35 and 1.40 and 1.45v as maximum, do not go over for 24/7 operation.  Admittedly these were for overclocking, so it could well be that the CPU itself handles these voltages and actually can take in quite some volts to it's power distribution, which in turns sends out more sensible levels internally.  When overclocking is enabled, the power controller is less responsible and the user has to be mindful of not pushing volts into the thing.

As stated in a previous reply, running on 1.30v fixed is also fine and safe according to the AMD rep's reply.  Just that it's no longer within normal limits and may be unstable.

Looks like my chip might be a real low power consumer!

Please note that I am NOT overclocking.  My frequencies are as stock (entered in UEFI as 3400MHz).  The Boosting speeds is part of the CPU design.  I did not enter a clock speed higher than default.  I have no wish to overclock at the moment

datonyb wrote: you really should be able to get the volts lower at 3.8 mate as an example  my 1700 is at 3.9 and 1.325 volts and both the 1600 systems i tuned were at less than 1.35 on 3.8 ghz there will be a decent reduction in temps if you can lower it down to 1.35 from 1.4

From my recollection you had UFI P3.00 and was using P-states.  You moved to P3.10 still using P-states.  Now you have disabled P-states (auto) and set a fixed voltage?  

But P3.10 is ramping volts up and down for you, rather than the experience I have with P3.00 which treats static voltage as exactly that, a static non-moving voltage (with the exception of vdroop).

I may just up my UEFI to 3.10 just to see what I may be missing.  The temperature display control seems like something I'd prefer to have, reading T-die rather than T-ctrl or even T-socket.

Sticking rigidly to the dictionary definition here, if the voltage reduces when your CPU idles then that is NOT fixed voltage, and in which case the UEFI code is a lie!

However, in use it's actually what you/we would all want to see, so is not a bad thing, just another item to add to the list of misleading things.

I am going to go and grab the kWh meter and stat some testings today.  I will be documenting my findings.

The question of all CPUs not being created equal is not an issue for debate, it's a fact.  Even the same SKU (model number/type) will show variances between samples.  Manufacturing anything, and especially equipment with fine tolerances, and even more so such tiny and intricate multi-million component count 'devices' like CPUs is bound to show some 'slop' between samples.  Some will go faster, generate less heat and require less voltage than others.  Others won't go so fast, but could be more efficient in normal modes.  Couple in the very fact that an 1700 is a 1800X with some things disabled and it gets more blurry.  Is a particular 1700 model a 1700 because it failed the 1800X and 1700X tests, or is it there because demand was higher, and they needed a few more 1700 chips to sell?

I haven't tried lowering the frequency of my CPU (I mean,  why would I ???), but I know that if any change is made to increase frequency the on-chip SMU automatically disables CPB and in-turn XFR.  CPB being the single/dual threaded load turbo boost and XFR being the slight boost across the board if temps/volts/current and stability(?) allows.

The annoyance for me, and it seems others, is that the 1700X and 1800X are both instructed to pull a 1.55v when under XFR boost - it can be seen in HWInfo64 as each core's VID.  Whilst I think this number is true (1.55v max), the exact plotting of it and it being on each core may be reported BS.  Under all-core loads the actual voltage draw is closer to ~1.2v despite the default 1.35v being what I think is set.  Maybe that's some vdroop, maybe not.

When single/dual thread loads are placed on the CPU, the CPB+XFR makes the CPU pull in those VID voltages, or at least close to.  This is why the vCore is reported at ~1.5v

Now, I do read that AMD have said this is by design, it's normal and it's safe.  

I just feel uneasy about it , when they have said 1.45v is really an upper max - why can't people use 1.5v for overclocks then if ~1.5v is safe?

I think we are missing the fact that the tools we have cannot report what is truly happening fast enough to get a proper representation.  I also think that the information that so far has been tapped into is a bit misleading, the system isn't providing quite the things we have grown accustom to expect to see.  For instance, put the Windows Power Plan to "Ryzen Balanaced" and core frequency never drops, but I think it might well be doing so 'behind the scenes' and unreported to the system.

It would not surprise me in the slightest to discover that M$ haven't got things properly locked in with Ryzen yet, being that Intel is such an aggressive company and that AMD's CPUs have been less desirable and less popular.  It's not unsupported per-se but it's not fully supported in terms of monitoring.

I shall get to some testing before I continue waffling here!

Your screen shots tell me a lot!  #1 well, setting the "CPU Voltage(V)" volts here don't do diddly under P3.00.

#2 Of course!  Fixed mode has an "auto" option by default.  P3.00 does not.  Undr P3.0 as soon as you enter Fixed, it shows 1.35000.  I will re-investigate setting 1.30000 in the top section and Fixed "Auto" in the lower.  

It didn't occur to me when I first saw it, although I did feel scared when I saw auto not a number....I panicked when I typed 1.30000 and crossed my fingers and hoped it'd boot without the smell of toasted silicon.

I will go try shortly!

Thanks for posting these images, it really tells a lot.

@ zlobster: Well, they kind of have put an end to the debate, but without a technical and acceptable reasoning.  Voltage spikes up to 1.55v ish is all part and parcel of the normal behaviour of single/dual core operation.  What I can extrapolate from their comments is that CPB and then XFR requires this kind of voltage for the worst possible chips off the production line to hit their advertised speeds.  It's safe and normal.

You have an issue of high idle temps which is not this, from what I gather.  High idle temps is a mess in your particular system somewhere.  Setting a static 1.30v or letting it auto up/down volt (even excessively in my opinion) still keeps idle temps down real low.  I'll confess it's about about 10°C +/-5 in my room, but still my Tdie is 20°C.

Are you sure you are reading T-die not T-ctrl or T-socket? 

So just what vCore reference do we use???

HWinfo64:

CPU:

Core # VID:  This is the requested voltage from each core.  It maybe a false data point but the actual number seems to read correct, even if it might not be for each core necessarily.  Auto ranges from 0.400 (idle) to 1.200 (all-core) to 1.550v (single/dual core boost XFR), it varies between of course.

CPU Core Voltage SV12 TFN: Requested(?) or Input voltage(?) into the SMU, or the front end voltage distribution and controller on the CPU.  Shows vDroop when higher voltages are required.

Nuvoton:

Vcore: motherboard vCore reported.  Jumps around all over the place down to ~0.300v but up to near defined static voltage - vdroop.

IRF PRM chip:

VR Out: Follows CPU Core SV12 TFN pretty darn closely with a small margin of error.  A graphical plot follows really well.

Other software doesn't seem to be able to read T-die nor CPU SV12 TFN.  I believe the motherboard HW Monitor tab reports the same Vcore as from the Nuvoton.

I think it's utterly insane that a company puts out a product and advertises it as an easily user tweakable device, yet doesn't provide any way to actually measure some crucial data.  Well, they haven't come out and said monitor your motherboard controller chip (Nuvoton or whatever) is the source you should read.  

CPU-Z, UEFI "HW Monitor", ASRock A-Tuning*, OpenHardwareMonitor all use the Nuvoton as the source for vCore.

Not much offers the ability to even see the CPU data.

* A-tuning 3.0.184 Doesn't really track the vCore shown in HWInfo64 Nuvoton, I think its a latency/timing issue as the same values do crop up, but out of sync.  Definitely it's not following SV12 TFN voltage.

I'd love to read through a white paper on this kinda stuff.  The Stilt was getting there...

This is a damn mine field!

Anyone know how to safely measure the voltage with a DMM?  TaiChi has no special easy measuring points like Asus ProbeIt.